Unsigned BigInt Doesn't Fit into Long, but jOOQ Correlates Them about jooq

[lukaseder]

This is a duplicate of:
https://sourceforge.net/apps/trac/jooq/ticket/519

See the discussion here:
https://groups.google.com/forum/#!topic/jooq-user/p_G7Cg8V8Xc

With UNSIGNED BIGINT, the probem is not very relevant. As you say, extreme values are needed. But with UNSIGNED TINYINT there could be trouble.

The best workaround I've found so far is something like this:
http://mindprod.com/jgloss/unsigned.html

Maybe, unsigned numbers could be wrapped in some library:
http://stackoverflow.com/questions/8193031/is-there-a-java-library-for-unsigned-number-types

I also like your idea of storing unsigned values as String and only convert them to Byte / Short / Integer / Long when needed. I'd personally prefer the next larger number type, rather than String, though:

UNSIGNED TINYINT
-> contains Short
-> declares Field
UNSIGNED SMALLINT
-> contains Integer
-> declares Field
UNSIGNED INT
-> contains Long
-> declares Field
UNSIGNED BIGINT
-> contains BigInteger
-> declares Field

However, while the user could decide to convert those values to String when reading them, writing them leaves open questions again. Simply declaring Field or Field for SMALLINT can lead to other problems, considering that you can use numbers that are too large for SMALLINT...

What database are you using, by the way?

[dacc]

We're on MySQL, and we use the unsigned bigint to store hash codes from CityHash, so almost every value tends to be up there at the top of the range. Hibernate treats them as Strings without a problem, and luckily we don't need to read them from the new jOOQ code.., yet. =)

[lukaseder]

I thought so. With enum types, it can almost only be MySQL...
I see, I hadn't thought of hash codes, only generated ID's. So I realise that I should make this a high priority for 2.0.0 or 2.0.1...

On a side-note: How is migration from Hibernate to jOOQ working out for you? I'd be very interested in a success-story. If this is a success-story for you, after all :-)

[dacc]

We're just using jOOQ in some areas where we need lower level access. I think Hibernate serves our other use cases pretty well, though.

[lukaseder]

I see. That, too might make for an even better success story :)

Tell me if you see room for improvement in the interaction between jOOQ and Hibernate/JPA, e.g. with ResultQuery.fetchInto(Class<?>)

I think I'm going to implement the wrapper solution and open-source those wrappers in an independent module:
http://code.google.com/p/joou/

With the wrappers, everyone's needs are covered. The needs of those that need Number types, of those that need Strings, and of those that don't care (they can call .longValue() etc, on the wrappers)

By default, jooq-codegen will use the wrappers for unsigned types. There will be a configuration flag, to avoid using those wrappers, like today:
https://sourceforge.net/apps/trac/jooq/ticket/960

Also, in jOOQ 2.0.1, I'll be implementing custom type mapping for more fine-grained usage of unsigned data types:
https://sourceforge.net/apps/trac/jooq/ticket/947

I'm closing this issue as it will be implemented with
https://sourceforge.net/apps/trac/jooq/ticket/519

[ebrandsberg]

More information on this topic at: http://www.jooq.org/doc/3.0/manual/reference/reference-data-types/data-types-unsigned/ in relation to how JOOQ deals with this topic.