Hi Lukas, I want to come back on something I said, now that the nights has passed and some thoughts came to my mind.
It is used by jOOQ to know how to bind and inline custom types in >> SQL. A custom type can only be converted by a single converter, >> globally. i.e. it is currently not possible to have MyEnum -> >> Converter1 in one place, and MyEnum -> Converter2 in another. The >> reason for this is, jOOQ needs an unambiguous registry in >> "context-less" cases like this: >> create.select(MyEnum.VAL).fetch(); >> > MyEnum is a field, so if a converter is attached to the field definition somehow, then it is unambiguous. Having different converters resolving to the same custom type is actually important and I have a practical test case. In our code base, we store 3 types of dates with the same custom type (let's call it MyDateType): - Dates, where null means a null date. - Dates used as min dates of ranges, where null means -infinity. - Dates used as max dates of ranges, where null means +infinity. MyDateType has states to represent -infinity or +infinity. It is up to the converter to convert null to the right value. It is also up to the converter to convert from MyDateType to null for the appropriate values and reject by throwing an exception when value is forbidden in the field context (e.g.: passing +infinity for a min date). If this cannot be supported, then it means we will have to pre/post process values with our own converters which defeats the purpose of this type mapping. Please let me know what you think! -Christopher
