Hi Christopher,
>>> 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.
I'm not sure what you mean. In my example, MyEnum is an enum type, and
VAL is a value of type MyEnum. In other words, this query corresponds
to
SELECT 'VAL' FROM DUAL
There is no "field" involved in this case. That's why a central
registry is needed here, to find a converter for the custom type
MyEnum, which is passed to jOOQ without "context"
> 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.
I'm not sure if I understand this design. Why would you use NULL for
something other than NULL? That smells fishy to me. Can you show some
examples where this would be practicable?
Cheers
Lukas
