This sort of follows on from what I was doing in Question 24256. I successfully managed to get and write arbitrary objects using the transcoder there and got my application-level code to work.
I’m now trying to do “the same thing” using the exciting new transactions API. But it seems that the relevant overload of get() is missing, and instead the transcoder is pulled directly from the Cluster Environment. While I understand how to insert a transcoder there, part of my “get” process is to indicate which “transaction” the object is in, which is only really obtainable by having one transcoder instance per transaction.
Is this functionality on the roadmap? Or are there reasons it is not possible?
Hi @gareth, I’m the developer of the Java transactions API. Great to have your feedback.
As you know, the API has only just hit 1.0.0, and the goal with the initial release was to hit the most common use-cases of handling JSON with gets, inserts, removes and replaces, and that’s the only real reason for the currently limited custom transcoding support. We can certain look at improving that going forward. My initial thoughts would be to add a new .get() overload that takes a TransactionGetOptions block that can take a transcoder, and probably a deserializer too. Plus add similar to the existing TransactionReplaceOptions and TransactionInsertOptions. And to PerTransactionConfig, to allow a per-transaction transcoder to be specified.
I’ve created Log in - Couchbase database to track this. I can’t offer any ETA at this time, but I think that using JsonObject as an intermediary works for you at the moment? E.g. you aren’t blocked, but this improvement would provide a degree of optimization?
Correct. I was in fact just writing those exact lines of code.
More than anything else, it was just having moved to 3.0 (without transactions), I was expecting it to be “easy” to switch to the transactions API, and over the past day I’ve been surprised at how many differences there are (e.g. no “async” API as opposed to reactive), and this felt like it might be significant.
Well, while I’ve tried to keep it similar to the Java API in many respects, transactions are a different beast and they do require some differences. E.g. replace() has to take a TransactionGetResult so it can check if the document is part of another transaction, so it can’t look exactly like the Java API’s replace().
But in some places it’s simply because we needed to prioritize the most common use-cases for the 1.0 release, and I felt a CompleteableFuture API wasn’t an initial priority. It’s certainly something I can consider adding - and I’ve created an enhancement ticket for it here https://issues.couchbase.com/browse/TXNJ-181.
Would you mind enumerating other places where you felt some friction with the API, or where it diverged significantly from the Java API?
@gareth the reason that we only offer a limited set of APIs is that it is not a 1:1 mapping in terms of number of operations. Each one of those logical TXN operations maps to a “couple” of ops underneath, and as @graham.pople said we are planning to extend that in the future but wanted to start with a well-understood version from which we can expand on.
Thanks @gareth. I’ve created tickets for those two - if you hit other things please feel free to either raise them here, or directly in our issue tracker (you can sign up Sign up for Jira - Couchbase database) on the “TXNJ” project (it’ll get assigned to me).
Sorry if it sounds like I’m complaining; I’m certainly not meaning too. As you know, this is something I’ve been hoping for for a while and it’s very exciting. I just want to try and understand what the parameters are and where it will be going in the future.
I realize I’m on the bleeding edge, but that’s where the fun is, right?