2017-03-20 15:39 GMT+01:00 Oded Arbel <[email protected]>:
> > On Friday, March 17, 2017 at 11:36:18 AM UTC+2, Lukas Eder wrote: >> >> 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. >> > > That would be great. I often use ORM libraries that allow me to write the > business logic "close to the data". The current implementation of Jooq is > not really suitable to ORM style business logic - its just OO data access, > which I think is a shame - it forces the user to manage another set of > objects for business logic. > Well, that's your opinion. Ours is: You should write your business logic in SQL, in the first place :) On a more serious note: You have a very strong opinion on how to design your DAOs and how to implement "business logic". jOOQ is just a SQL abstraction library with basic unopinionated mapping. Having added these DAO types in version 2.4 (2012) was one of the most controversial decisions. It was a quick win over a competing framework and it kinda made sense for very simple use-cases, but the number of opinionated requests to extend DAO functionality on this list shows, that there simply isn't "a right solution" that fits everyone, but a whole set of "opinionated solutions" that fit few people only. Compare this to Spring Data's repositories who are *extremely* opinionated (and thus rigid). I'm not sure if we really should continue extending DAOs in jOOQ. I've postponed the option of deprecating them time and again, but I think the time is now ripe to formally discuss it: https://github.com/jOOQ/jOOQ/issues/5984 (sorry, this is a bit more context than just an answer to your request) > 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. >> > > Well, I need the DAO to generate my subtypes when it creates new record > instances, otherwise I can't expose business logic through the record type. > I don't mind the DAO using the base POJO type in method definitions, as my > subtype is assignable. > > looking at DAOImpl now, I can see that I just need to overwrite the POJO > type generated into the DAO constructor code. Unfortunately - again, no > extensability, so there's no way to replace just that without overwrite the > entire `generateDao()` method or hacking away just at `pType`. > At this point, I would probably just conclude that jOOQ's DAOs won't help you. Looking at DAOImpl, however, you will also see how extremly simple the current implementation is, so perhaps rolling your own will just be much easier (and lead to less disappointment)? > > `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. >> > > I feel that there is likely a way to protect assumptions by documenting > them well and putting in checking code that will cause the build or library > initialization to throw exceptions when assumptions are breached, but I > have no concrete knowledge so I'm probably mistaken here. > Excellent. So we've built in a language feature that causes your build to fail if you break our assumptions (notably extending those classes) :) Again, on a more serious note: You're not mistaken. The problem is that the feature you're looking for is not there, and if you could extend things, you would build on ill-defined internals that will break in the future. > > > 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. >>> >> >> Would be interesting to look at, definitely! Thanks for the offer. >> > > Please see attached. This is not based directly on the Jooq JavaGenerator, > instead I'm using the https://github.com/jklingsporn/vertx-jooq > VertxGenerator so I'm sub-typing that - but the code should be easily > adaptable to use JavaGenerator directly and the magic is all in the > `OverridableJavaWriter` anyway. The JavaWriter sub-type just uses string > searches (yuck, I know) to identify the original POJO type name and replace > it with a matching "concrete type" if such exists in the configured > "concrete implementation package". > > The main problem I had was that some well behaving generators use the type > name as an argument to `JavaWriter.println()` which allows me to do a > direct string match and be happy, while others - notably `VertxGenerator` > like to use `String.format()` to embed the type name in large strings that > are then passed to `JavaWriter.println()` as the first argument - forcing > me to do string searches... > Thank you very much for sharing. I wasn't aware of that VertxGenerator. I think this is another fine example of why we should completely re-design the code generator for extension points to be predictable, rather than people just hacking their custom behaviour into the generator through overriding (which at this stage is about as stable and predictable as actually patching the real generator). Anything in that generator can just break between minor releases - but that's our fault. We should have taken the generator API / SPIs much more seriously from the beginning. Thanks again for sharing and for your thoughts. This was a really nice example showing the importance of a couple of next steps in jOOQ. 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.
