In Java SDK 2 bucket.insert(…) and bucket.upsert(…) methods return Document objects that contains contents of updated/created document. In SDK 3 collection.insert(…) and collection.upsert(…) methods return MutationResult object and as far as I understand one can’t retrieve document contents from this object directly. What is the best way to get updated/inserted document in SDK 3? There is nothing on this topic in migration documentation. After reading through documentation I found the Transactions approach: Using Couchbase Transactions | Couchbase Docs
Is it the most efficient way of retrieving updated document content? Is CB response ratio of this approach is equally or more efficient compared to SDK 2 insert/upsert
Hi @khan - In what case would the contents of the updated/created document be different from the argument that was passed to upsert/insert? Using get() would be the most efficient - but unnecessary since the client already has it.
Hi @mreiche thank you for your answer. for example in case of remove I want to get the document I just deleted. in sdk 2 the remove method returned the doc. now one have to use transactions. are transactions as efficient in sdk 3 as remove method in sdk 2?
another case, binaryCollection.append(). we don’t have full data, we just pass chunk of bytes to be appended to the existing document but we never get the whole document back. how do I perform append and get the result in single transaction?
I don’t have any good answers for remove and binaryCollection.append(). I would suggest making a new post indicating specifically those two issues. ( insert and upsert are not issues )
You can do a get() and save that doc and the CAS, followed by a remove() call which includes the CAS obtained from the get(). If the remove succeeds, then the doc from the get is exactly what was removed. If the remove fails with CAS-Mismatch, then repeat the get() followed by the remove(). AFAIK, this would be the most efficient way to get the exact document that was deleted. This would avoid using transactions (which would be less efficient). You could also use n1ql "DELETE … returning " , but n1ql is less efficient than the kv api.
For binaryCollection.append(), I think you would first get(), then append (using the cas from the get) and save the new CAS, and then get() comparing with the CAS from the append. This method would still allow the document to be modified between your append() and your get() - but at least you would know that it was modified from the CAS.
It’s worth noting that the Document returned by SDK 2’s remove method does not contain the content of the removed document. From the Javadoc:
The Document returned just has the document ID and its CAS value set, since the value and all other associated properties have been removed from the server.
If you want the content of the document you’re removing, @mreiche 's solution with optimistic locking (CAS) is the way to go, in both SDK 2 and SDK 3.
For the binary append operations, the strategy is the same. Get the existing document and remember the CAS. Then do the append operation and specify the CAS. If it fails with a CAS mismatch exception, start over. Otherwise, you know the document now has the original bytes plus the bytes you just appended.