jooq 3.11.0 breaks UpdatableRecordImpl when globalObjectReferences is set to false

[Beldrew]

A change (#5537) stops the generation of Keys.java when set to false.  However UpdatableRecordImpl calls "getPrimaryKey().getFieldsArray()" on line 164 which ends up calling the default getPrimaryKey() in AbstractTable which returns returns null causing a null pointer exception.

It looks like the code generator is assuming Keys exists, and not generating overloads for getPrimaryKey() if it doesn't.

[Lukas Eder]

Thanks a lot for your report. You're right, I can reproduce the problem. The problem went undetected because the integration tests for #5537 only checked for compilation errors in code produced by that particular code generation flag, not for this particular runtime problem.

I have created an issue for this:

https://github.com/jOOQ/jOOQ/issues/7554

Will fix the issue with high priority. By the end of next week, jOOQ 3.11.1 will ship with a fix.

In the meantime, the workaround is to turn on the flag again.

Thanks again,

Lukas

Am Fr., 8. Juni 2018 um 03:11 Uhr schrieb Beldrew <bel...@gmail.com>:

A change (#5537) stops the generation of Keys.java when set to false.  However UpdatableRecordImpl calls "getPrimaryKey().getFieldsArray()" on line 164 which ends up calling the default getPrimaryKey() in AbstractTable which returns returns null causing a null pointer exception.

It looks like the code generator is assuming Keys exists, and not generating overloads for getPrimaryKey() if it doesn't.

--
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.

[Beldrew]

Oh you might want to highlight "#7419 Rename jooq-meta and jooq-codegen packages to avoid conflicts in JPMS" a bit more, had to go look up the new packages for JavaGenerator and my db dialect (mysql) in GitHub.  Not hard but being my first jooq upgrade it threw me for a bit.  

And one quick question about 3.11.0 #6627 Add DateToLocalDateConverter, TimeToLocalTimeConverter, TimestampToLocalDateTimeConverter: does this 'fix' mysql Date column being offset by a day?  Or is this a JPA issues like google searches suggest tho why the JPA is applying time zone information to a column type that doesn't have one is beyond me...  I'm at the point where I'll probably change it to a datetime field just to have timezone info so I can make sure it stays as UTC.

[Lukas Eder]

Am Fr., 8. Juni 2018 um 13:03 Uhr schrieb Beldrew <bel...@gmail.com>:

Oh you might want to highlight "#7419 Rename jooq-meta and jooq-codegen packages to avoid conflicts in JPMS" a bit more, had to go look up the new packages for JavaGenerator and my db dialect (mysql) in GitHub.  Not hard but being my first jooq upgrade it threw me for a bit.  

Thanks for the hint. That's a good idea. I'll look into it - this can be improved both in the release notes and in the error message that is displayed when the old package names are used. I've created an issue for this:

https://github.com/jOOQ/jOOQ/issues/7556

 

And one quick question about 3.11.0 #6627 Add DateToLocalDateConverter, TimeToLocalTimeConverter, TimestampToLocalDateTimeConverter: does this 'fix' mysql Date column being offset by a day?  Or is this a JPA issues like google searches suggest tho why the JPA is applying time zone information to a column type that doesn't have one is beyond me...  I'm at the point where I'll probably change it to a datetime field just to have timezone info so I can make sure it stays as UTC.

I'm sorry, I'm not quite sure what you mean. Would you mind being a bit more specific?

Do note: For future visitors, it will be very helpful if there was only one discussion per topic. It will be much easier to track down individual topics and read only what's relevant in any given context.

Thanks,

Lukas

[Beldrew]

So I have a MySql 8 db with a Date column, mapped to LocalDate on the java side.  Have JOOQ generating java.time dates.  I store a date, its fine in the db.  I retrieve it and it's a day behind.  I'm guessing some kind of time zone conversion is happening somewhere behind the scenes and some googling on it suggests it's the JPA.  Was hoping that LocalDate to Date converter would help but it still occurs after I upgraded.

Sorry about the multiple topics, was in my brain as '3.11.0 questions'

[Lukas Eder]

Thanks for the details. I'm unaware of such an issue. I'm happy to help, but I really need more details on the topic. By details, I mean a reproducible test case. Here are some guidelines on how to create one:

https://stackoverflow.com/help/mcve

[Lukas Eder]

Am Freitag, 8. Juni 2018 13:03:37 UTC+2 schrieb Beldrew:

Oh you might want to highlight "#7419 Rename jooq-meta and jooq-codegen packages to avoid conflicts in JPMS" a bit more, had to go look up the new packages for JavaGenerator and my db dialect (mysql) in GitHub.  Not hard but being my first jooq upgrade it threw me for a bit.  

For the record, I have now also documented this change on Stack Overflow, which should help find this issue more easily:

https://stackoverflow.com/q/50793357/521799