2015-09-29 17:28 GMT+02:00 <[email protected]>:

> Thanks Lukas.
> If I added a custom convertor, would that just impact the `Record` setters
> and getters or would that also update the fields in the TableImpls?
>

Every type reference will be updated, including TableImpls, POJOs, etc.


> If it did the later as well I could see where that might make even selects
> more difficult.
>

Yes, indeed.

Could you give me a simple example of where it makes it more difficult?
>

If your column is:

TableField<MyTable, Optional<String>> TEXT;


Then, you won't be able to call built-in functions like
DSL.substring(Field<String>, int), because the types don't match. It's a
relatively high price to pay for little additional value.

Another example, consider the column

TableField<MyTable, Integer> ID;


Obviously, an ID column is hardly ever nullable, thus you'll model that
with Integer (as opposed to Optional<Integer>)

Now, you create a LEFT JOIN like this:

Result<?> result =
    select()
    .from(MY_OTHER_TABLE)
    .leftOuterJoin(MY_TABLE).on(...)
    .fetch();


What does the following yield?

result.get(0).getValue(MY_TABLE.ID)


You would get an Integer value, even if you should be getting an
Optional<Integer> value, because after a LEFT JOIN, you might get NULL
values even for NOT NULL columns.

There's no workaround for the latter. SQL has NULL. Java has null. The two
special values are just the best match for each other (even if they're not
exactly the same). Optional seems like a good idea at first, but it is not,
when you work with SQL.

I hope this helps,
Lukas

On Tuesday, September 29, 2015 at 2:52:45 AM UTC-5, Lukas Eder wrote:
>>
>> Hello,
>>
>> Yes, you can implement a Converter for this and hook your Converter into
>> the code generator:
>> http://www.jooq.org/doc/latest/manual/code-generation/custom-data-types
>>
>> It will be a bit of work as there is no way to match all nullable columns
>> in the code generator configuration - you'll have to match them all by
>> name. Currently, we do not have any out-of-the-box support for this, just
>> as we do not have Option support in the jOOQ Scala integration. One of the
>> main reasons is the fact that the Option(al) type is rather difficult to
>> enforce in the context of:
>>
>> - outer joins
>> - functions
>> - grouping sets
>> - unions
>> - etc.
>>
>> Hope this helps,
>> Lukas
>>
>> 2015-09-28 22:20 GMT+02:00 <[email protected]>:
>>
>>> Is it currently possible to generate Record classes that return a java 8
>>> Optional type for nullable fields?
>>>
>>> Thanks,
>>> James
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "jOOQ User Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "jOOQ User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "jOOQ 
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to