Hi Steve, Thank you very much for your enquiry. Great to hear from you!
Indeed, I have thought about #3 quite a while ago, and rejected the thought in the end. This is one of the things that Hibernate really does exceptionally well. But it does so at a price. The price is that it is mainly a CRUD framework. Now, of course, Hibernate developers couldn't resist and also offer explicit bulk and batch operations in a "Hibernate way", which means they're not really as powerful as what could be done with SQL directly. Users who confuse CRUD (you modify entities only) and bulk (you write explicit DML statements) will constantly fight Hibernate and its various caches, because bulk statements often bypass the cache. For instance, up to this date, I'm unaware of an efficient AND easy way to query the Hibernate cache and the database in a transparent way, pretending they're the same thing, without wrestling edge cases, or simply flushing prior to every query. On the jOOQ side, we do resist, and we won't implement the JPA / Hibernate session semantics, because we really want to encourage people to use SQL and work with a SQL mindset. This might mean that some operations seem lower level. But it's also perfectly fine to use both jOOQ (for bulk) and Hibernate (for CRUD) in the same application. Now, there are some low-hanging fruit (#1 and #2), which do not constitute a paradigm shift for jOOQ. While I think it is impossible to reorder (or even skip) statements to optimise locking, it is certainly possible to let users be explicit about network protocol optimisations. For instance, there is a pending feature request to collect statements within a lambda, and execute them all in one (or several) JDBC batches at the end: https://github.com/jOOQ/jOOQ/issues/3419 Of course, this behaviour can already be achieved via DSLContext.batch() explicitly, but issue #3419 will expose a simpler programming model to the user. However, it isn't trivial. The question is: What happens with interleaved reads? What happens with other, side-effectful operations that need to be executed in the correct serialised order? Can this be detected and mitigated, or will it simply be documented? So, I think that would be the issue to vote on. Of course, if you have other ideas for such optimisations that do not alter any query semantics, I'm very open to discussion! Best Regards, Lukas 2016-04-11 16:27 GMT+02:00 Steve Ash <[email protected]>: > One of the features that I like in hibernate is the buffering that happens > in the session cache. I can write my code and do things and then > flush/commit the whole session at once. This allows hibernate to (1) > automatically batch (prepare + bind) the dml (2) delay the statements so > that db locks are held for minimum amount of time (instead of execute, > round trip, do more app work, etc.), (3) hibernate re-orders the dml to > avoid deadlocks. That's a pretty powerful combo for high throughput oltp > systems like I tend to work on. Some kind of simple "session" concept that > could aggregate/buffer jooq dml statements to flush them at a later point > in time seems not too difficult. Could at least get #1 and #2 benefits > pretty easily with this. #3 seems a little more tricky. I'm not sure that > jooq should be in the business of doing things like this. But a simple > mechanism to buffer dml work and auto-batch it seems right in the jooq > wheelhouse. > > Any plans for this? A github issue I can vote for? > > -- > 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. > -- 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.
