Hi Stefan, Thanks for your message.
Well, my answer here will be very biased of course. :) On Sun, Sep 24, 2023 at 7:56 PM Stefan Sator <sator.stefa...@gmail.com> wrote: > I've searched in this user group, but all the conversations on this topic > are pretty old. > Yes, the user group doesn't discuss things much anymore. I think that most users have moved to github these days, and that's far less interactive (between users). I've tried activating github's "discussion" feature, but that doesn't seem to pick up momentum. Neither does the /r/jOOQ subreddit. Plus, ChatGPT has picked up a lot of knowledge about things, so I guess the time of mailing lists has passed. > I have often read that Hibernate is good for storing complex object > graphs, but I could not find an example. > In my opinion, the reason why you're not seeing examples of storing complex object graphs is manifold: 1. It is very hard to write good examples of complex logic, as examples try to be simple. At the same time, while successful complex object graph persistence applications must exist within corporations (otherwise, RedHat / IBM wouldn't invest so much in maintaining Hibernate), they tend not to share that with the public in a way that is suitable for examples. 2. Much like mailing lists have faded away, awesome, in-depth blogs have faded as well, at least in google searches, as content marketers and "influencers" have started sharing thousands of meaningless (but simple!) hello world tutorials. Every new "startup" needs 1-2 devrel people who don't really deeply understand any subject matter, yet they'll start blogging away to generate traffic for their product. Look at jOOQ articles out there. One of the top google results (that aren't from jooq.org) is this: https://www.baeldung.com/jooq-count-query. I mean, really? A dumbass COUNT(*) query? 😅 That isn't why you need jOOQ. You could just use JDBC for that, too. But it makes sense for baeldung to write about this, because baeldung aims for helping beginners getting started, and a beginner probably looks up a COUNT(*) query with jOOQ, not virtual client side computed columns ( https://blog.jooq.org/create-dynamic-views-with-jooq-3-17s-new-virtual-client-side-computed-columns/), or client side row level security ( https://blog.jooq.org/implementing-client-side-row-level-security-with-jooq/ ). 3. I, for one, have never seen an application that is better suited for an object graph persistence approach than just SQL based ETL. While that's just anecdotal evidence, I do believe that it correlates with the majority of software out there. Hardly anyone needs the most powerful features of JPA. (For the record, before jOOQ, I used to maintain applications that would generate 500-line Oracle execution plans that ran in < 1ms against billions of rows: https://twitter.com/lukaseder/status/1227260757726957568. A big amount of logic was implemented in SQL and PL/SQL.) But then, when the visible examples are always simple, the perceived value of using object graph persistence fades, and SQL based alternatives become more compelling, objectively. Yet, because of inertia, things tend not to change drastically, and as such, people who probably *should be* using more SQL to become much more effective, continue to use Hibernate instead, because that's what they always did. Vlad Mihalcea from Hibernate fame keeps advocating the Lindy effect: https://en.wikipedia.org/wiki/Lindy_effect. You could also say: "Nobody ever got fired for choosing IBM", if you're more cynical. Ironically, the Lindy effect also applies to SQL and Java, so there's probably no objective answer to your questions. Regarding effectiveness, I keep quoting this tweet: https://twitter.com/baevdm/status/1423636838275768322 Or my famous talk: https://www.youtube.com/watch?v=wTPGW1PNy_Y One of the things I used to say in talks is that it's ironic. Back in the 90s, when SQL optimisers still sucked, *everyone* was writing their applications purely in SQL. Today, when optimisers are really really awesome, people have moved to other paradigms than SQL. But luckily, SQL has been seeing some sort of "renaissance" in the industry over the past decade, probably because NoSQL was such a sobering experience. > Do you know of such an example? Even if Hibernate is good at storing a > complex graph, I don't understand why it would be so much harder to do this > with jooq. > Oh, if your database has 1000s of tables, and you have tons of graphs of 50 connected entities that have to be persisted as a unit within a transaction, then you won't be very happy with any pure SQL based approach. Just imagine the work of having to serialise all the SQL in the correct order. I mean, it will still be very difficult to achieve with JPA as well, but at least, it will be obvious how JPA will help you here. But again, 1. Writing such an example is very hard work, so you don't see an example. 2. Who really has such persistence problems? For most 1-2 table based persistence, jOOQ's UpdatableRecord are more than enough to simplify the boring parts of CRUD. 3. When you have said 1000s of tables, *querying* the tables with SQL will be much more effective than navigating the object graph, for the reasons I mentioned in the above talk. I hope this helps, 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 jooq-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO6Bwa4K4rRVTEVJCcg8c%2BUmF-zriVihR_PmPe0fKXPTVQ%40mail.gmail.com.
