2013/8/27 <[email protected]> > > 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<https://github.com/jOOQ/jOOQ/issues/2713> >> >> > Thank you :) > > >> For more sophisticated enums, you might need to completely override the >> JavaGenerator.generateEnum() method. >> >> > The "cleanest" approach would probably be: > - parse the skeleton source code for the class definition, extracting type > signature, implemented interfaces, static initializers, constructors, and > methods. > - then generate the enum class merging the stuff jOOQ wants to put there > with the former definition > But this sounds like using an BFG9000 to kill some sparrows :( >
I have to remember that way of saying it :-) 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? >> > > My first idea has been the approach described above: Reading an actual > enum class file that contains no enum values, parsing that, generating a > new class using the stuff described above. > When you ask for templates in a "velocity" style, what could one achieve ? > The enums would be quite simple, just omit the values in the skeleton, jOOQ > fills them in and adds its own stuff, > taking care that no methods or properties with the same name exist. If you > provide dummy values in the skeleton, the file could be statically typed by > the compiler. That is good. > If you use an "velocity template" the compiler/eclipse could not make head > or tail of the skeleton. That is not so good. > I think you might underestimate the task of "correctly" parsing an "empty" enum source file - including the amount of documentation to add to the manual, and the support to give for such a feature. Given that currently, only PostgreSQL and MySQL support enum types, I prefer to find a more generic solution that is applicable to all generated source files, not just to enums. When you ask for templates in a "velocity" style, what could one achieve ? You get full control over the complete rendering of the generated enum. Enum converters will allow you to use custom enums and map them to database >> types. >> >> > Well yes, but I can't inherit from enums, so the enums I convert the > generated enums to can't get information concerning the values from the > enums generated from jOOQ. > I can't think of a way to dynamically construct an enum using values from > another enum (I'm not good at reflections) and even if reflection would do > the trick, I am not > going to like it, because that imposes a lot of overhead and is not easy > anymore. > > Plus, I like jOOQ especially because I can use the database definitions to > have ONE authority for the enums, pojos, records. > Having to map them to another class kind of defies that purpose. > OK, but you can still override the jOOQ generator and generate your own enum class, the way you prefer... Cheers 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.
