Hi Oded, Thanks for your message. We're aware that the version 3.0 of our code generator lacks the extension capabilities that many users desire, and we definitely will improve it heavily in version 4.0. At the moment, however, I will not be able to give you a solution that is more than a workaround.
I will comment inline 2017-03-16 12:57 GMT+01:00 <[email protected]>: > 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. > It does look like a bad idea, but at some point, you're just generating code and perhaps, you might want to adapt other things later, and eventually, writing your own templates might actually be the better idea than patching a generator that is not yet ready for arbitrary extension. After all, generated DAOs don't really contain a lot of content themselves... > Ideally I would have liked to just override the `pType` inside > `generateDao()`, but there's no extension point for that and the likely > candidate - > I'm not sure if that's the right candidate. It will map to the generated POJO class, whereas you'd like it to return a subtype. But returning a subtype might break a lot of assumptions that are made throughout the code generator, so this might not be the right place after all. > `AbstractGeneratorStrategy.getFullJavaClassName()` is final and cannot be > overridden (why a final in an abstract class?!?). > To protect the assumptions that are otherwise made in the code generator. There had been quite a bit of criticism on this list about our usage of "final". The criticism is understandable, but it criticises the wrong thing. Final is just a tool to ensure correctness. The problem is the fact that the jOOQ 3.0 code generator is not really as extensible as many people would like. If there hadn't been a final modifier on that method, you would have run into another issue further down the line. 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. > Sure, that's another option if replacing that one class name is all you'll do in your case. > I'm willing to share the implementation if anyone is interested. > Would be interesting to look at, definitely! Thanks for the offer. 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/d/optout.
