Hi Lukas, 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 >
I think here is the mistake: only fields or converters should be used: VAL should not be allowed. The special case of DUAL would require the converter. I am not sure what syntax it should look like, but using a type which can map to a single conversion logic will cause problems (there are actually several cases I thought about). 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" > Let's take the example I provided (we will discuss the "fishiness" of it later in this e-mail). Let's consider 3 converters: MyRangeBeginDateConverter MyRangeEndDateConverter MyRangeDateConverter If I read a value from dual, I may want the -infinity, +infinity, null, or a date depending on the business usage of that date. It is up to me to add the right conversion. create.select(MyRangeBeginDateConverter.to(MyEnum.VAL)).fetch(); or something like that. Type checking should be enforced so that invalid combinations are prevented (like using the enum directly, etc). Note that I know that I want a begin date for a range in the above example, so I don't think jOOQ should do hidden magic to resolve that value: explicitely using the appropriate converter makes sense. > 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? > We have the notion of a range, where [startDate, endDate] is so that a range can either be [-inf, date], [date1, date2] (date2 obviously greater than date1), and [date1, +inf]. null is not allowed because a range cannot have an unknown bound. It is logical to store that range as 2 dates, and the inifinity is the same as a missing date (no lower/upper bound) but our code does not allow nulls for ranges. The RDBMS stores that null. Our code could handle a null, but our logic is so that non-null dates (-inf, +inf) work with all date comparisons without having to do any null checks. Those 2 dates are obviously of the same type, which happens to be the same type as our regular dates (which do not allow +-inf but allow nulls). >From a business point of view it makes sense, and I don't see what is wrong with this design. Of course, we can discard that use case labeling it as "fishy" to simplify jOOQ's impementation, but I don't think it should work that way :) -Christopher
