Hi Steve, I'm sorry for the delay in this matter. I had been on the road at conferences...
I will comment inline: 2016-04-15 22:34 GMT+02:00 Steve Ash <[email protected]>: > 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? > The way the API is "designed" in the issue: Yes. But using ThreadLocal is a bad idea, and when the transaction API was designed, there was a lot of discussion around how to do this, i.e. whether to implement the transactional lambda as a pure function (as I finally did), or as a mere closure (as was suggested by others, and as is suggested by https://github.com/jOOQ/jOOQ/issues/3419). I'm still convinced that the pure function approach, where the lambda receives a new configuration is better. That way, the batch can be collected into the Configuration.data() map where it belongs, rather than in some obscure ThreadLocal that breaks in asynchronous environments, for instance. I'll fix the issue text right away. 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. > You're right. Although I would definitely want to design the API in a way that allows for using lamdbas. Note that the lambda is optional. You can always pass an anonymous class as in the old days. > 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 > We already have that API (in a way). It's DSLContext.batch(Query...). Although, in its current form, it only supports a single batch without bind variables. But that's a good hint anyway. This API design will certainly be the least surprising, and also rather easy to implement. I'll add that as a remark to the issue. There are advantages to both approaches, but as things get more complex, the currently suggested approach will inevitably blow up as someone will certainly (perhaps accidentally) bypass the functionality in one way or another, e.g. by using JDBC directly, and that will be rather hard to debug. Thanks again for your suggestions! 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
