Follow-up on DATACOUCH-212. While the former has been resolved in its basic form, Aloren has raised concerns that the case of multiple concurrent saves (and even inserts) has not, as no OptimisticLockingException is raised in such a case
Affects: 2.1.1 (Hopper SR1)
DATACOUCH-212 Optimistic Locking is not working when using Repository save method
This change introduced some unexpected consequences as for the patch version. Documents that were routed to upsert branch of SAVE operation before are routed to insert (there's versionProperty but there's no version value) now and fail because of key duplication
The assumption is that if you're using an @Version annotated property, you want CAS. So either the document doesn't previously exists, in which case you cannot have a version, and that translates to an insert, or you want to update an existing entity, in which case you want CAS and thus should provide a version.
If you don't want insert+CAS, but rather upsert, then you probably don't need a version property?
That's true, in my use case all CB accessors produce consistent result on a particular key at a given time so even when one of them updates document the rest are fine to do nothing/overwrite it. I'm not questioning the change itself, it looks good and proper. My point is that replacement of upsert with insert is restrictive and so potentially breaking as it was in my case