The _version_ field used to optimistic concurrency can't be user supplied -- it's not just a record of the *document's* version, but actually a record of the *update command* version -- so even deleteByQuery commands have one -- and the order must (internally) increase across all types of updates to a shard to ensure that they are executed in the correct order across all replicas.
However... Your use case sounds like an exact match for the DocBasedVersionConstraintsProcessorFactory described here... https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents#UpdatingPartsofDocuments-DocumentCentricVersioningConstraints http://lucene.apache.org/solr/5_4_0/solr-core/org/apache/solr/update/processor/DocBasedVersionConstraintsProcessorFactory.html : Date: Mon, 14 Dec 2015 22:47:43 +0530 : From: Debraj Manna <subharaj.ma...@gmail.com> : Reply-To: solr-user@lucene.apache.org : To: solr-user@lucene.apache.org : Subject: Providing own _version field in solr doc : : We have a use case in which there are multiple clients writing concurrently : to solr. Each of the doc is having an 'timestamp' field which indicates : when these docs were generated. : : We also have to ensure that any old doc doesn't overwrite any new doc in : solr. So to achieve this we were thinking if we can make use of the : _version field in solr doc and set the _version field equal to the : 'timestamp' field that is present in each doc. : : Can someone let me know if the approach that we thought can be done? If not : can someone suggest some other approach of achieving the same with minimum : calls to solr? : -Hoss http://www.lucidworks.com/
