Configuring default enum converter for project without code generation

[Guillem Corominas]

Hi,

At my company we are using Jooq since a long time ago.

I am now migrating an old application from Java 8 to Java 11, and I was trying to bump a 3.11 version of Jooq to the latest open-source available for Java 11 (3.16)

As I was saying in the title, we only use Jooq for its DSL query generator, but we are not using the code generator.

I am seeing that with the prior version, Jooq mapped automatically String into Enums, but since the upgrade it doesn't. I suppose by calling its valueOf() method.

Type type = record.getValue("loc_type", Type.class);

The statement above worked fine with Java 8 and Jooq 3.11, however now with Java 11 and Jooq 3.16 I get:

org.jooq.exception.DataTypeException: Cannot cast from class java.lang.Object (instance type: class java.lang.String to class java.lang.Object

Is there any way to globally activate the mapping of Strings to Enums as a setting for all the application? 

thanks in advance

Guillem

[Lukas Eder]

Hi Guillem,

Thanks for your message.

On Wed, Feb 7, 2024 at 9:09 AM Guillem Corominas <gcoro...@dexma.com> wrote:

Hi,

At my company we are using Jooq since a long time ago.

I am now migrating an old application from Java 8 to Java 11, and I was trying to bump a 3.11 version of Jooq to the latest open-source available for Java 11 (3.16)

As I was saying in the title, we only use Jooq for its DSL query generator, but we are not using the code generator.

Why not? I have to ask, because you're missing out on the best features of jOOQ, even more so when you upgrade to 3.16

https://blog.jooq.org/why-you-should-use-jooq-with-code-generation/

 

I am seeing that with the prior version, Jooq mapped automatically String into Enums, but since the upgrade it doesn't. I suppose by calling its valueOf() method.

Type type = record.getValue("loc_type", Type.class);

The statement above worked fine with Java 8 and Jooq 3.11, however now with Java 11 and Jooq 3.16 I get:

org.jooq.exception.DataTypeException: Cannot cast from class java.lang.Object (instance type: class java.lang.String to class java.lang.Object

Is there any way to globally activate the mapping of Strings to Enums as a setting for all the application? 

My first guess is, of course, that this is a problem that could have been avoided with code generation (see again the above article). I'm assuming you didn't provide the data type binding for your enum while constructing the query, creating just DSL.field("loc_type") without type information. And then, the information got lost somewhere.

But I cannot be 100% sure. I'll need more context to answer this question, including a complete reproducer. Our issue tracker on github asks for an "MCVE" (minimal, complete, verifiable example), e.g. based on this template here: https://github.com/jOOQ/jOOQ-mcve. Sometimes, it may not be necessary to create such a complete example, but it's certainly helpful, ensuring that the exact behaviour can be reproduced. Otherwise, such emails just tend to ping-pong back and forth until it's clear what exactly you're doing.

[Guillem Corominas]

Hi Lukas, thanks for your fast response,

Let me reply inline too:

El dia dimecres, 7 de febrer del 2024 a les 9:17:24 UTC+1, lukas...@gmail.com va escriure:

Hi Guillem,

Thanks for your message.

On Wed, Feb 7, 2024 at 9:09 AM Guillem Corominas <gcoro...@dexma.com> wrote:

Hi,

At my company we are using Jooq since a long time ago.

I am now migrating an old application from Java 8 to Java 11, and I was trying to bump a 3.11 version of Jooq to the latest open-source available for Java 11 (3.16)

As I was saying in the title, we only use Jooq for its DSL query generator, but we are not using the code generator.

Why not? I have to ask, because you're missing out on the best features of jOOQ, even more so when you upgrade to 3.16

https://blog.jooq.org/why-you-should-use-jooq-with-code-generation/

I was not directly involved in the decision of using Jooq (and to which extent) when we started using it, and now it is quite large monolith. We will definitely try it out first in a micro-service from scratch and evaluate if it is worth the adoption in this project.

My current urge is to migrate it Java11, and I have to upgrade Jooq as well in order to do so. 

 

I am seeing that with the prior version, Jooq mapped automatically String into Enums, but since the upgrade it doesn't. I suppose by calling its valueOf() method.

Type type = record.getValue("loc_type", Type.class);

The statement above worked fine with Java 8 and Jooq 3.11, however now with Java 11 and Jooq 3.16 I get:

org.jooq.exception.DataTypeException: Cannot cast from class java.lang.Object (instance type: class java.lang.String to class java.lang.Object

Is there any way to globally activate the mapping of Strings to Enums as a setting for all the application? 

My first guess is, of course, that this is a problem that could have been avoided with code generation (see again the above article). I'm assuming you didn't provide the data type binding for your enum while constructing the query, creating just DSL.field("loc_type") without type information. And then, the information got lost somewhere.

Sure, but I understand that it is not mandatory to use code-generation, and as I said, this mapping was performed automatically (without binding the enum while constructing the query), in Java 8 and Jooq 3.11

 

But I cannot be 100% sure. I'll need more context to answer this question, including a complete reproducer. Our issue tracker on github asks for an "MCVE" (minimal, complete, verifiable example), e.g. based on this template here: https://github.com/jOOQ/jOOQ-mcve. Sometimes, it may not be necessary to create such a complete example, but it's certainly helpful, ensuring that the exact behaviour can be reproduced. Otherwise, such emails just tend to ping-pong back and forth until it's clear what exactly you're doing.

I will try to get it working a bit more, and if not try to create a MCVE, in any case, if you know any tip that may help me advance, it will be appreciated.

I have already tried adding a jooq-config.xml file and add this section (without configuring the connection with the DB), but it doesn't seem to have any effect

<forcedTypes>
   <forcedType>
      <enumConverter>true</enumConverter>
   </forcedType>

</forcedTypes> 

thanks again,

Guillem

 

[Lukas Eder]

On Wed, Feb 7, 2024 at 9:38 AM Guillem Corominas <gcoro...@dexma.com> wrote:

Hi Lukas, thanks for your fast response,

Let me reply inline too:

El dia dimecres, 7 de febrer del 2024 a les 9:17:24 UTC+1, lukas...@gmail.com va escriure:

Hi Guillem,

Thanks for your message.

On Wed, Feb 7, 2024 at 9:09 AM Guillem Corominas <gcoro...@dexma.com> wrote:

Hi,

At my company we are using Jooq since a long time ago.

I am now migrating an old application from Java 8 to Java 11, and I was trying to bump a 3.11 version of Jooq to the latest open-source available for Java 11 (3.16)

As I was saying in the title, we only use Jooq for its DSL query generator, but we are not using the code generator.

Why not? I have to ask, because you're missing out on the best features of jOOQ, even more so when you upgrade to 3.16

https://blog.jooq.org/why-you-should-use-jooq-with-code-generation/

I was not directly involved in the decision of using Jooq (and to which extent) when we started using it, and now it is quite large monolith. We will definitely try it out first in a micro-service from scratch and evaluate if it is worth the adoption in this project.

My current urge is to migrate it Java11, and I have to upgrade Jooq as well in order to do so. 

I just have to mention this every time I encounter some usage of jOOQ without code generation, because code generation really helps prevent tons of issues, especially if they're data type related. I'm aware that this isn't your immediate concern here, but it's definitely good to keep in mind.

 

I am seeing that with the prior version, Jooq mapped automatically String into Enums, but since the upgrade it doesn't. I suppose by calling its valueOf() method.

Type type = record.getValue("loc_type", Type.class);

The statement above worked fine with Java 8 and Jooq 3.11, however now with Java 11 and Jooq 3.16 I get:

org.jooq.exception.DataTypeException: Cannot cast from class java.lang.Object (instance type: class java.lang.String to class java.lang.Object

Is there any way to globally activate the mapping of Strings to Enums as a setting for all the application? 

My first guess is, of course, that this is a problem that could have been avoided with code generation (see again the above article). I'm assuming you didn't provide the data type binding for your enum while constructing the query, creating just DSL.field("loc_type") without type information. And then, the information got lost somewhere.

Sure, but I understand that it is not mandatory to use code-generation, and as I said, this mapping was performed automatically (without binding the enum while constructing the query), in Java 8 and Jooq 3.11

I can't comment on this yet before I can reproduce the issue.

 

 

But I cannot be 100% sure. I'll need more context to answer this question, including a complete reproducer. Our issue tracker on github asks for an "MCVE" (minimal, complete, verifiable example), e.g. based on this template here: https://github.com/jOOQ/jOOQ-mcve. Sometimes, it may not be necessary to create such a complete example, but it's certainly helpful, ensuring that the exact behaviour can be reproduced. Otherwise, such emails just tend to ping-pong back and forth until it's clear what exactly you're doing.

I will try to get it working a bit more, and if not try to create a MCVE, in any case, if you know any tip that may help me advance, it will be appreciated.

I would really need to at least first see the entire query, even before making wild guesses.

 

I have already tried adding a jooq-config.xml file and add this section (without configuring the connection with the DB), but it doesn't seem to have any effect

<forcedTypes>
   <forcedType>
      <enumConverter>true</enumConverter>
   </forcedType>

</forcedTypes> 

That's a code generation feature ;-)