Repository navigation
Preserve the Class-based TypeHandlerRegistry registration descriptor - #3840
Conversation
Delegate the Class overload to Type registration and cover the legacy method descriptor and registration paths. Related to mybatis#3837.
|
coverage: 87.469% (+0.02%) from 87.45% — wozhenbang2004:fix/type-handler-class-compat into mybatis:master |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
@harawata Thoughts on this? I think following the original work, expectation is that it should be labeled as deprecated if accepted. |
|
@wozhenbang2004 I think its feasible to do so, need @harawata to chime in. I do think it needs to be marked deprecated like some of the others were to be consistent and drive consumers to the new one. |
Direct callers to Type-based registration and replace deprecated lookup assertions with identity checks on freshly registered handler instances.
|
Thanks, added the deprecation annotation and a Javadoc link to the Type overload. The focused tests and the unchanged 3.5.19-compiled client still pass. |
|
@wozhenbang2004 Thanks, lets give @harawata some time to see this. Appreciate quick response. |
| nullTypeRegistry.register((Class<?>) null, null, nullTypeHandler); | ||
| assertTrue(nullTypeRegistry.getTypeHandlers().stream().anyMatch(registered -> registered == nullTypeHandler)); | ||
| } | ||
|
|
| void shouldKeepTypeRegistrationOverload() { | ||
| Type javaType = new TypeReference<List<String>>() { | ||
| }.getRawType(); | ||
| TypeHandler<?> handler = new ObjectTypeHandler(); |
|
Thank you for the PR, @wozhenbang2004 ! I just took a quick look and...
If you need me to add a line comment on each method for clarity, please let me know and I will work on it later. Note that, even if we resurrect those methods, it does not guarantee the same behavior (there were inconsistencies between those methods with [1] I actually planned to move By the way, in the constructor, some of the lines registering the built-in type handler may need explicit casting (e.g. |
|
Thanks @harawata, the scope here is just the three-argument Class bridge; no TypeReference or String overloads are being restored. Added explicit Type casts to all 27 built-in registrations in the constructor in c244402, so they call the Type overload directly. The compatibility tests still deliberately exercise the deprecated Class entry point. The new CI workflows are awaiting maintainer approval. |
Related to #3837.
This adds back the three-argument
register(Class, JdbcType, TypeHandler)entry point as a small bridge to theTypeoverload. It preserves the JVM descriptor used by previously compiled clients without changing Type-based handler resolution.I understand #3379 deliberately introduced breaking changes. Would keeping this particular entry point be acceptable? A client compiled against 3.5.19 throws
NoSuchMethodErroron 3.6.0 and runs unchanged with this bridge.Validation on JDK 17:
These were focused checks; I haven't run the full Maven build, formatter, database integrations or Flowable startup.