Hello,
2013/8/26 <[email protected]>
> Hi,
>
> since the ordering of the enum is now correct (thank you very much :) I
> now encounter another "problem" , but this is not a bug....
>
> One thing I like about enums is that you can add code. One can implement a
> lifecycle, for instance, with a state transition matrix,
> and has little trouble implementing that with an enum.
>
> For instance:
>
> public enum ApplicationLifeCycle {
> [...]
> }
>
> My point is, that enums are very versatile, MINUS you CAN'T INHERIT, only
> implement.
>
> It would be great if the enums I define in the database server could be
> "enhanced" with code.
> Means: if jOOQ could use a "enum skeleton" to render generated code, one
> could easily add a lot of functionality
> and logic based on the enum values in the database.
>
I've thought about this before. When generating code for Row[N], Record[N]
and similar types (Row1, Row2, ..., Row22, ...), I have written a little
utility, which is capable of overwriting only parts of generated files:
https://github.com/jOOQ/jOOQ/blob/master/jOOQ-tools/src/org/jooq/xtend/Generators.xtend
The generated files can be "annotated" with comment marker sections, such as
// [jooq-tools] START [select]
...
... generated code here
...
// [jooq-tools] END [select]
Only code within such sections will be re-written. In the event of the jOOQ
code generator, sections delimiting user-code wouldn't make too much sense
for two reasons:
1. Most users don't version-control generated code, i.e. the source for
user-code should not be put inside generated code.
2. Such sections might give the impression that several of them are
possible, which is not the case as it is hard to merge user-code with
generated code.
On the other hand, you're right, it should be possible to provide
"skeletons", or rather: trailing custom code. It would be rather easy for
the JavaGenerator class to provide some callback methods that custom
subtypes can override. I'll register this as #2713
https://github.com/jOOQ/jOOQ/issues/2713
Or, apply some fixing. For instance the Calendar.DAYS_ENUM_VALUES in Java
> start with #1, and the
> enums ordinal starts (correctly) with #0. If one could supply a skeleton
> enum with mapper function, one
> could fix some issues with numbering and other inconsistencies in the
> database.
>
For more sophisticated enums, you might need to completely override the
JavaGenerator.generateEnum() method.
But as I pointed out above with the lifecycle, there could be other
> applications too.
>
> From my point of view, there should be a configuration option that
> specifies a skeleton for a specific class.
> A skeleton enum/class file must then contain code, but NOT the enum values
> definition, which will be generated by JOOQ.
>
Currently, code is generated using Java. Hence, such enhancements should be
written in Java as well. A more long-term, more sophisticated option would
be to entirely rewrite the current generator using something like velocity,
or Xtend, as had been suggested on this user group before. I suspect by
"skeleton files", you actually mean templates, such as in velocity
templates?
> I have read the documentation concerning the enum converters.
>
> http://www.jooq.org/doc/3.1/manual/sql-execution/fetching/data-type-conversion/
>
> But I think this feature is different.
> What do you think about it?
>
Enum converters will allow you to use custom enums and map them to database
types.
Regards,
Lukas
--
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
