1

My application is working fine before I included custom type converter. I need to convert jOOQ UInteger to Integer, so I included a type converter to achieve this. Post this change, I am getting a mysql syntax error on limit and offset.

Then while debugging, I found that all Integer values that are being supplied(including limit and offset values) are converting into UInteger(because of the type converter) and in turn to string since UInteger is not a default type.

I could solve this by the solution provided by the link jooq issue with limit and offset but I want to understand some details.

  1. If I use settings.setStatementType(StatementType.STATIC_STATEMENT) I cannot get prepared statement and I might miss the advantages of the PreparedStatement.

  2. If I use Factory.inline to bind all integer inline values, I have to do this over my complete application and if I miss something, it will result in serious issue.

Kindly help me out to solve the issue or give me some suggestions on the same.

Community
  • 1
  • 1
dbyuvaraj
  • 487
  • 1
  • 6
  • 20
  • I feel you're mixing a couple of things in this question: Type conversion, bind variable inlining. What kind of issue are you trying to solve now? – Lukas Eder May 21 '13 at 20:49
  • I want to use type conversion without binding variables inline. Because I cannot bind all the variables inline – dbyuvaraj May 22 '13 at 04:52
  • I still don't quite understand how conversion and variable binding are related... Is this about trying to avoid some conversions? What was the original problem that you were facing? – Lukas Eder May 22 '13 at 06:50
  • Original problem is: since I am using custom type converter to do a conversion between Integer and UInteger type, all integer values including limit and offset values are getting converted to UInteger rather than converting only **_ids** which are actually configured while generating jOOQ classes.. Hope you get my problem!! – dbyuvaraj May 22 '13 at 07:28
  • Yes, I understand that, and you shouldn't do that for the reasons mentioned in [this ticket](https://github.com/jOOQ/jOOQ/issues/2467). That's a design flaw in jOOQ's dealing with converters. But how can I now answer this question? There isn't really any question left in this Stack Overflow question, in my opinion. The question from my side is, why are you trying to use converters in the first place? Couldn't you just use UInteger.intValue() ? – Lukas Eder May 22 '13 at 09:01
  • I can use UInteger.intValue() but I have to do this throughout the application to get the integer value from DB call. If I can directly get an integer value from the DB call instead of UInteger value, it will make life more easier – dbyuvaraj May 22 '13 at 11:02

1 Answers1

0

I think what you're looking for is a way to completely disable the generation of unsigned integer types. The relevant code generation flag is documented here:

http://www.jooq.org/doc/3.0/manual/code-generation/codegen-advanced

An excerpt:

<!-- Generate jOOU data types for your unsigned data types, which are
     not natively supported in Java.
     Defaults to true -->
<unsignedTypes>false</unsignedTypes>

Otherwise, there is an undocumented solution to force types onto another SQL type rather than onto a converter. The documentation task is this one here:

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

This isn't properly tested, but in the case of converting between UInteger and Integer it might work quite well. An example from the integration tests can be seen here

<forcedType>
    <name>UUID</name>
    <expressions>(?i:(.*?.)?T_EXOTIC_TYPES.UU)</expressions>
</forcedType>

In your case:

<forcedType>
    <name>INTEGER</name>
    <expressions>YOUR_COLUMN_MATCHING_EXPRESSION_HERE</expressions>
</forcedType>

Note that you can always change your database schema to actually hold signed types, instead of unsigned ones.

Lukas Eder
  • 211,314
  • 129
  • 689
  • 1,509
  • yeah this is the one I tried first but my senior is not happy with this since it completely removed unsigned types concept. In some cases, we need unsigned types and not for some. That's why we went for the other option called Custom type converter. – dbyuvaraj May 22 '13 at 11:23
  • If it is a design flaw for now, can I expect a fix for this issue in the near future? – dbyuvaraj May 22 '13 at 11:24
  • @Yuvaraj: If you don't need "unsignedness" for some columns, then why declare them unsigned in the database? Unfortunately, I cannot give you any guarantee about when the "Converter issue" is going to be fixed, but see the updated answer for an alternative solution. – Lukas Eder May 22 '13 at 11:44