lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per Steffensen <st...@designware.dk>
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 http://wiki.apache.org/solr/HowToContribute. It is possible 
for "outsiders" (like us) to get a SVN branch at svn.apache.org 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 
request")?

Thanks!
Per Steffensen

Em skrev:
> Hi Per,
>
> Solr provides the so called "UniqueKey"-field.
> Refer to the Wiki to learn more:
> http://wiki.apache.org/solr/UniqueKey
>
>   
>> 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
>>
>>     
>
>   


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