Hello Christopher,

Sorry for the delay. This E-Mail was lost in my mailbox

> Let's be practical. In the world, there are only few real enumeration types:
> - int values.
> - String values.
> - Eventually char values (e.g.: Y/N), which are like Strings of length one.

You're probably right. And since jOOQ doesn't support
Field<Character>, CHAR(1) and VARCHAR(1) and similar are also String
values. Thinking about it, the JPA @Enumerated annotation only
distinguishes between ordinal and string enum literals, too:
http://docs.oracle.com/javaee/6/api/javax/persistence/Enumerated.html

Speaking of which, this annotation should be rendered in generated
POJOs with <pojos/> and <jpaAnnotations/> both set to true. That's
https://sourceforge.net/apps/trac/jooq/ticket/1197

> Maybe you could have a contractual API: if a getEnum method is
> available through reflection (loaded only once per enum and cached so
> not a performance issue), then this API is used. [...]

This feels a bit fuzzy. I'd like to re-use the existing EnumType
interface and its getLiteral() attribute, even if itis nullable for
Integer wrappers. In fact there's nothing wrong with that, as NULL is
an acceptable enumeration value in SQL and jOOQ doesn't distinguish
nullable and not-nullable fields, so far.

Other options than making EnumType<T> generic are likely to introduce
incompatibilities for my MySQL and Postgres users, where true enums
(as opposed to synthetic ones) already exist. Besides, there can still
be static lookup methods outside of the enum, as implemented for Pay
in MySQLFactory.

> If not, it would
> iterate on the values() until intValue() returns the expected one.
> Performance improvements would just be a matter of implementing the
> getEnum method. Alternatively (or in addition if the getEnum method is
> not declared), jOOQ could iterate once per enum and establish that
> mapping once and for all, though I don't know if that can have nasty
> performance issues in practical case (I doubt it).

Enum.valueOf() works in similar ways. It maintains a global dictionary
that is maintained in java.lang.Class.enumConstantDirectory. I can get
some inspiration there...

Cheers
Lukas

Reply via email to