Thanks, Samir 2016-05-26 23:35 GMT+02:00 Samir Faci <[email protected]>:
> I also have a use case where I need to inject some additional SQL to be > executed within the same transaction. > Would you mind elaborating your use-case a little bit? > the code snippet you describe would sound ideal for us. > > > ctx.beginTransactionAsync() > .thenApply(... -> ...) > .thenApply(... -> ...) > .thenApply(... -> commit()); > > So far, this was just a very high level sketch. Let's assume we'd be going this way. There would be two new alternative transaction APIs: A blocking one and a non-blocking one. The blocking one might look just like JDBC or JTA: Transaction transaction = ctx.beginTransaction(); ctx.insert()... ctx.update()... Savepoint savepoint = transaction.savepoint(); ctx.delete()... transaction.commit(); The non-blocking one would need to maintain the transaction state throughout the .thenApply() call chain, exposing it in case someone wants to nest stuff (using savepoints) or commit/rollback early. The difficulty of this is that CompletionStage is not designed for this use-case. It is designed for passing only computation results to the next computation, not (transaction) contexts. This means that the context needs to stay external or implicit, which also violates the CompletionStage design. One option would be to subtype the JDK's CompletionStage and make that a TransactionalCompletionStage. So, more specifically than what I've stated earlier: ctx.beginTransactionAsync() .thenApply(transaction -> transaction.ctx().insert()) .thenApply(transaction -> transaction.ctx().update()) .thenApply(transaction -> transaction.savepoint()) .thenApply(transaction -> transaction.ctx().delete()) .thenApply(transaction -> commit()); Where "transaction" would be that TransactionalCompletionStage<T>, where <T> is the outcome of the previous computation (Integer in case of insert/update/delete, Result in case of fetch, Void in case of savepoint). I'm a bit wary of implementing that, though. There hasn't been a lot of literature around, documenting such things (as with subtyping the Collections API). I'm very open to hear your thoughts on this matter. Best 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.
