@harawata Do you still want to bring this in? Seems like its an ok idea.

@hazendaz ,

It wouldn't hurt, I guess :)
I'll update the comments/headers.

@hazendaz @harawata How about including this in version 3.6.X

@GeorgeSalu ,

Um...the idea looks even less attractive in 2025... 😓
Given that it is pretty easy for users to copy these legacy type handlers, I think we should just close this PR.

I agree that they are simple and that is why I think it would be a good idea to have these "basic" handlers, just as I have copies in several projects, for example, of a handler that converts tinyint to boolean for MySQL. It would be good if we already had these "basic" handlers at least.

@hazendaz @epochcoder

If either of you are OK with this, feel free to merge.
I want to keep my hands clean. 👋 ✨😆

@harawata What if we split out type handlers completely and then allow that to be a slush fund of handlers? Really anything in core that starts to feel lite its more than just core intent should be extracted out for more modular design. Not sure that would entirely help but I know I could offload a couple type handlers I support at work since core doesn't support them. I'm sure others based on comments are in the same boat. I know we had a type handler library before but it was isolated to one type so maybe a catch all. Even if we don't actually release that, it would at least have a place we store for all to use and others could add to it. With some tricks folks could pull the source and build their jars with bits and pieces of that without having to repeat it. Easier to find source at very least to get folks started.

@hazendaz ,

I'm sorry, I'm very bad at understanding new ideas 😓
Let me clarify step by step.

What does "split out type handlers completely" actually mean?
Does it mean we move the interface org.apache.ibatis.type.TypeHandler (and its implementations) out of this repository and create a new module (e.g. mybatis-type-handlers) ?
Then, add the new 'type handler module' to the core's dependency?

@hazendaz ,

I'm sorry, I'm very bad at understanding new ideas 😓 Let me clarify step by step.

What does "split out type handlers completely" actually mean? Does it mean we move the interface org.apache.ibatis.type.TypeHandler (and its implementations) out of this repository and create a new module (e.g. mybatis-type-handlers) ? Then, add the new 'type handler module' to the core's dependency?

That was my thinking then, yes. Basically anytime something starts to become its own thing, I think it needs to be a separate module but we don't have to do that unless we really feel its needed.

Thank you for the reply, @hazendaz !

Then let's assume we did that (i.e. created a new module 'mybatis-type-handlers').
And you wrote that you can "offload a couple type handleres I support at work since core doesn't support them".
It means (I assume) that we should maintain those in-house type handlers created by you or other developers under the new mybatis-type-handlers repo, but I don't understand how it improves the situation for anybody.

Here is what people are currently doing (or should be doing) if they maintain in-house type handlers.
They 1) create their own module e.g. 'mycompany-typehandlers', 2) put their custom type handlers in that module and 3) use it in their projects (it can be published to private repository or maven central if it makes things easier).
In each project, the developer needs to 1) add the module to the dependency list and 2) specify type-handnler-package in the config.

Now, even with the new 'mybatis-type-handlers' module, people have to follow the same step, basically i.e. 1) add 'mybatis-type-handlers' to the dependencies and 2) specify 'type-handler-package' in the config.
But, it could get worse, actually, because it is reasonable to assume that there will be multiple different type handler implementations for the same type (e.g. UUID [1]).
And if that happens, people will no longer be able to rely on the handy 'type-handler-package' and may have to specify each type handler explicitly.

I probably am misunderstanding something, but am not sure what.

[1] Different DB/driver requires different type handler implementation for UUID. c.f. #3286 (comment)