lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per Steffensen <>
Subject Re: Unique key constraint and optimistic locking (versioning)
Date Wed, 22 Feb 2012 08:27:50 GMT
Thanks a lot. We will use the UniqueKey feature and build versioning 
ourselves. Do you think it would be a good idea if we built a versioning 
feature into Solr/Lucene instead of doing it outside, so that others can 
benefit from the feature as well? Guess contributions will be made 
according to It is possible 
for "outsiders" (like us) to get a SVN branch at to 
prepare contributions, or do we have to use our own SVN? Are there any 
plans migrating lucene/solr codebase to Git, which will make it easier 
getting a "separate area" to work on the code (making a Git fork), and 
suggest the contribution back to core lucene/solr (doing a Git "pull 

Per Steffensen

Em skrev:
> Hi Per,
> Solr provides the so called "UniqueKey"-field.
> Refer to the Wiki to learn more:
>> Optimistic locking (versioning)
> ... is not provided by Solr out of the box. If you add a new document
> with the same UniqueKey it replaces the old one.
> You have to do the versioning on your own (and keep in mind concurrent
> updates).
> Kind regards,
> Em
> Am 21.02.2012 13:50, schrieb Per Steffensen:
>> Hi
>> Does solr/lucene provide any mechanism for "unique key constraint" and
>> "optimistic locking (versioning)"?
>> Unique key constraint: That a client will not succeed creating a new
>> document in solr/lucene if a document already exists having the same
>> value in some field (e.g. an id field). Of course implemented right, so
>> that even though two or more threads are concurrently trying to create a
>> new document with the same value in this field, only one of them will
>> succeed.
>> Optimistic locking (versioning): That a client will only succeed
>> updating a document if this updated document is based on the version of
>> the document currently stored in solr/lucene. Implemented in the
>> optimistic way that clients during an update have to tell which version
>> of the document they fetched from Solr and that they therefore have used
>> as a starting-point for their updated document. So basically having a
>> version field on the document that clients increase by one before
>> sending to solr for update, and some code in Solr that only makes the
>> update succeed if the version number of the updated document is exactly
>> one higher than the version number of the document already stored. Of
>> course again implemented right, so that even though two or more thrads
>> are concurrently trying to update a document, and they all have their
>> updated document based on the current version in solr/lucene, only one
>> of them will succeed.
>> Or do I have to do stuff like this myself outside solr/lucene - e.g. in
>> the client using solr.
>> Regards, Per Steffensen

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message