> 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 > > 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 :( > 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. 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. Best, Patrik -- 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.
