I certainly agree that the mismatch of bulk and crud in hibernate is a huge source of leaks in their abstraction. I apparently was already watching that issue you referenced. That approach would certainly be an improvement. did that rely on some kind of threadlocal that the context consulted to batch instead of execute things? For short little lambdas that syntax in java8 is nice. However, perhaps the magic batching is too much of a violation of the principal of least surprise even with the lambda acting as a nice lexical reminder of the enhanced semantics.
Perhaps another design would be to segregate the DML operations of DSLContext into a separate interface (e.g. DmlOperations) and then you could do something like: Batcher b = dslContext.createBatcher(); // could do DML operations like expected just like on DSLContext but they will be buffered b.insertInto(...) b.insertInto(...) b.update(..) // then execute at the end b.execute() And the semantics would be: 1) everything happens in the order you execute it 2) if you have adjacent statements that can be auto-parameterized and jdbc batched (i.e. preparedstatement + addbatch) then they will Seems pretty straight-forward to me, avoids the nasty interleaving reads semantics problem, gets the batching performance advantages #1 and #2 without cluttering up the readability of the code (BatchBindStep etc), and doesn't only benefit java8 folks. On Tuesday, April 12, 2016 at 1:29:33 AM UTC-5, Lukas Eder wrote: > > 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] <javascript:>>: > >> 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] <javascript:>. >> 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.
