JSR 310 support in Jooq 3.7

[Denis Miorandi]

Does anyone used Java 8 LocalTime, LocalDate or LocalDateTime?

My configuration is based on

• sqlserver 2012 express
• jdbc 4.2 driver from Ms. (I don't know if is mandatory for JSR310 in jooq)
  
• Java8 compiled version of jooq pro 3.7.0
• JDK 1.8.0_60

I expect to have sql types automatically mapped on java jrs310 types on generation but it doesn't. Actually my results are

• sql datetime ==> java.sql.TimeStamp
• sql date ==> Long
• sql time ==> java.sql.Time

Am I missing something? 

Tks

Denis

[Denis Miorandi]

Reading this https://github.com/jOOQ/jOOQ/issues/4429, I found that this addition is related to runtime. It seems

that for generator we need to wait 3.8.

[Denis Miorandi]

This worked for me inside generator/database tag of generator configuration. You have to write your own converter foreach type.

<customTypes>
	<customType>
		<name>LocalDateTime</name>
		<type>java.util.time.LocalDateTime</type>
		<converter>base.config.jooq.converters.LocalDateTimeConverter</converter>
	</customType>
	<customType>
		<name>LocalDate</name>
		<type>java.util.time.LocalDate</type>
		<converter>base.config.jooq.converters.LocalDateConverter</converter>
	</customType>
	<customType>
		<name>LocalTime</name>
		<type>java.util.time.LocalTime</type>
		<converter>base.config.jooq.converters.LocalTimeConverter</converter>
	</customType>
</customTypes>
<forcedTypes>
	<forcedType>
		<name>LocalDateTime</name>
		<expression>(\w+\.)?(?!UDT_PREFIX|PROC_PREFIX)\w+(\.\w+)?</expression>
		<types>DATETIME</types>
	</forcedType>
	<forcedType>
		<name>LocalTime</name>
		<expression>(\w+\.)?(?!UDT_PREFIX|PROC_PREFIX)\w+(\.\w+)?</expression>
		<types>TIME</types>
	</forcedType>
	<forcedType>
		<name>LocalDate</name>
		<expression>(\w+\.)?(?!UDT_PREFIX|PROC_PREFIX)\w+(\.\w+)?</expression>
		<types>DATE</types>
	</forcedType>
</forcedTypes>

[Lukas Eder]

Hi Denis,

Thank you for your enquiry and for your additional feedback. jOOQ's internals are ready for JSR-310 types, i.e. they can correctly bind java.time.* values to JDBC statements, and fetch them from ResultSets (give or take the usual bugs for new functionality).

However, we have not yet proceeded with implementing https://github.com/jOOQ/jOOQ/issues/4429 as you've noticed - i.e. source code generation support for JSR-310 types - for several reasons:

- We don't want to make those the default (yet)

- Much of jOOQ's API in org.jooq.impl.DSL expects some Field<? extends java.util.Date> types, e.g. timestampDiff. Because we cannot overload these functions based on their generic argument types due to generic type erasure, we need to re-think our source code generation strategy in this area.

We're in a bit of a catch 22 situation here. Without JSR-310, we cannot support TIMESTAMP WITH TIME ZONE types for those databases that have the type. With JSR-310, we'll break existing jOOQ API.

I'm hoping that we'll find a solution for jOOQ 3.8. Until then, you can always use converters, as you did.

I hope this explanation helps. Of course, we're very open to suggestions, as we might have missed something...

Best Regards,

Lukas

--
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 jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Denis Miorandi]

I understand your position. I had same issue on a pullrequest on another project compiled in java1.6...

I think is reasonable at now. No suggestions. 

Maybe have converters needed on 1.8 java time integrated in library could be nice, so that you have just to configure generation to switch to new one.

[Lukas Eder]

Hi Denis,

I'm not sure yet, if converters will be the right choice because the time-zoned data types will need to be implemented in a Binding (probably the DefaultBinding) to accommodate the various vendor-specific interpretations of these data types - e.g. the need for binding these values as VARCHAR. This will certainly be solved along with https://github.com/jOOQ/jOOQ/issues/4429

Best Regards,

Lukas