On Mon, May 20, 2024 at 4:49 PM fabio trabattoni <[email protected]> wrote:
> Thank you for your thoughtful response, Lukas. I'd like to clarify a few > points: > > I don't consider my idea revolutionary, nor do I aim to build the next big > framework from it. It was a simple attempt to solve a small problem. > > While my idea resembles GraphQL to some extent, GraphQL is far more > ambitious and comes with an "all or nothing" constraint. Additionally, I'm > not a fan of the "querying by JSON example" approach, but that's just a > personal preference. All I wanted is something that makes sense inside the > domain: there are books and there are rentals, what do you want to load? > And how? > > I wasn't aware of Oracle 23c AI, so I'll look into it as soon as possible. > > I did not intend to undermine or criticize jOOQ. I use it in every > project, all the time. As you mentioned, jOOQ is designed to mitigate the > impedance mismatch problem at large, not the simple traversal/filter issue > I proposed. It only makes sense that you decided not to include this > discussion as a new feature in jOOQ. > That wasn't my impression, I just wanted to make sure it's understood what can possibly belong in jOOQ and what cannot. I mentioned the DAO because it has a very long history of feature requests where users wanted "just" one more feature inside of the DAO. Every time, the answer was: Don't use the DAO for this, write a query, often to the disappointment of said users. And that kind of shows it's a mistake for a library like jOOQ to engage in such opinionated utilities, even if they are perceived as "useful templates" as Bernd called it. > My critique of MULTISET was poorly phrased. MULTISET is a fantastic > feature in jOOQ, possibly one of the best. However, it’s not a "pattern" in > and of itself. Like any flexible tool, it can get very ugly very quickly if > used by inexperienced developers. My idea was meant to act as a "cage" to > enforce a strongly defined approach for developers. > But jOOQ doesn't want to enforce cages. jOOQ is a collection of operators and statements, none of which have any weight or opinion attached to them. jOOQ isn't opinionated about almost anything. Don't care about 1NF? jOOQ doesn't care, it can work with your database. Do everything in 6NF? jOOQ doesn't care, it can work with your database. What users want to do, is up to users, of course. In my opinion, and I don't want to play the Martin Fowler here, the > impedance mismatch has won, database side. Almost every OOP > framework/architecture that accesses databases is generally designed around > inserts, updates, and selects. For instance, the classic layered > architecture is driven by the DAO/repository layer, which often results in > a procedural approach rather than an OOP one. Phrases like "composition is > favored over inheritance" seem to have been coined only to somehow relieve > us from the burden of this heart-felt truth. One of the reasons for the > recent success of Hexagonal/Onion architectures, to name another example, > is that they strive to bring us back to the fundamentals of OOP, don't they? > I wouldn't know. Luckily, I've been out of these loops for ages 😅 I've always found software architecture to be art for art's sake... Ultimately, as you suggested, the best approach might be to build an > opinionated API on top of jOOQ, similar to what I tried to achieve in my > demo application. > It can obviously work for you, and I'll be very happy to discuss any missing operator or missing convenience that helps you build this API more to your liking. Thanks again, and I apologize if I came across as aggressive or critical. Not at all! -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO7nNMCOAqFxCCrif8b7ZG2fOu2t2OtbFAWU5%2Bx75Xv5Bw%40mail.gmail.com.
