I've encountered the same problem and tried to come up with an elegant solution. Unfortunately, overriding and re-implementing generateDao() is not really feasible - there's a lot of code there and reproducing it is a bad idea.
Ideally I would have liked to just override the `pType` inside `generateDao()`, but there's no extension point for that and the likely candidate - `AbstractGeneratorStrategy.getFullJavaClassName()` is final and cannot be overridden (why a final in an abstract class?!?). My solution was to override the `JavaWriter` class and add a text level processor. Its not a good solution, but between Wrong Thing A and Wrong Thing B, I chose the one that is easier to understand, maintain and detect the error when it breaks. I'm willing to share the implementation if anyone is interested. On Tuesday, January 7, 2014 at 1:04:46 AM UTC+2, David Hogan wrote: > > I've achieved what I wanted with a JavaGenerator subclass that overrides > generateDao(TableDefinition > table). > > It's not at all elegant and will require revisiting each time I move to a > newer version of jooq, but will suffice in the very short term .. I guess > the other option is to move custom pojo object functionality into a > subclass of the generated DAO object, but it seems heavy to have to > instantiate a DAO for something like calling a custom toJson() method on a > POJO. It would be much simpler if pType could be overriden in the generator > strategy. > > > -- 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/d/optout.
