On Thu, Apr 4, 2019 at 5:16 PM sdwarwick <[email protected]> wrote:
> Thanks so much for your thoughtful response. I recognize now that my > expectations of maturity are a bit out of sync with reality at this moment > in time. > > I'd like to offer just an opinion that trying to keep up with the constant > changes/additions in all of the different SQL databases in the code > generator seems like a long term uneconomical use of your time. This > problem will only get worse as you onboard support for more databases that > have non-standard SQL/DDL which may be something you would be considering > for the commercial version of the product. > > just for an example use case, we have been using flyway for many years, > to the point where we had over 100 files doing incremental changes to the > database. As a performance improvement, we did a pgDump of the database > state ( not the table data... ) and replaced the 100 incremental files. > A lot of this dump is obscure and postgres-specific and not something we > actually want to "think" about. it just works when creating an image of > the database for testing and as a basis for further incremental changes. > I could imagine this happening for all of your supported databases. This > puts you in the position of having to interpret (even if "ignore") lots > and lots of obscure database-specific code. This would terrify me from a > product maintenance perspective. Not sure how I would deal with it, but > it seems to be a real problem. > I'm convinced the parser already adds a lot of value to the community, and it will add even more value in the future. I think you're overestimating the efforts to implement a solid 80/20 solution. Compare this to JPA. JPA has been popular for a while and it has always been an extremely limiting "80/20 solution". Take JPQL. It can't express the simplest of queries if one expects something remotely comparable to SQL. How could unions and derived tables not be supported? I'm not even asking for window functions. Yet it does add value for a subset of developers. jOOQ's parser will always add value for a subset of developers, and it's improving at a fast pace. So, thanks for sharing your opinion, with which I respectfully disagree :) In the case of JPA, I'm just wondering if there might be an opportunity > for a different approach. I notice that JPA/Hibernate generates > "companion" classes for each entity ( they take the class name and append > an underscore character ) I am assuming that the JPA/Hibernate folks > already have developed everything needed to directly interpret source code > to produce these companion classes. These companion classes may have all > of the needed information for generating the JOOQ classes. Perhaps there > is an opportunity to collaborate with the Hibernate folks in order to > create a bridge, or perhaps even extend the companion classes. Here, you > might be able to take advantage of a very mature and highly maintained > project to supercharge the JOOQ code generator and provide broad > compatibility with the JPA ecosystem. > This sounds much like what I had also suggested. You just made it sound much easier than I think it will be, due to the limitations of annotation processing. Maybe I'm wrong. If this is possible at all, yes, it will be done eventually. "Supercharge" - well, it will be an improvement. But entities that depend on services is not the rule, so for many projects, factoring out entities in a separate project is definitely viable and not totally orthogonal to Maven best practices. So, while definitely useful, I don't think we're discussing a game changer feature here. For the time being, jOOQ can offer you the discussed options. -- 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.
