Unfortunately, you cannot create that type, unless you "cheat":
@Override
@SuppressWarnings({"unchecked", "rawtypes"})
public Class<Optional<String>> toType() {
return (Class) Optional.class;
}
2015-09-30 18:01 GMT+02:00 <[email protected]>:
> Thanks Lukas. This really helps to understand all the ramifications.
> I would say we currently have a rather simple data structure. I took a
> stab at implementing a Convertor yesterday and got pretty close adding it
> for a specific field like you suggested in your first reply. My one problem
> was that I was unable to really do what I wanted for the `toType` method.
> For example I wanted it to look like:
>
> @Override
> public Class<Optional<String>> toType() {
> return Optional<String>.class;
> }
>
> Obviously the above won't compile but if you have any suggestions for a
> workaround I'd love to hear them.
>
> Thanks again for your help.
> James
>
>
> On Wednesday, September 30, 2015 at 10:38:22 AM UTC-5, Lukas Eder wrote:
>
>>
>>
>> 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.
>
--
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.
