Hi Per, well, Solr has no "Update"-Method like a RDBMS. It is a re-insert of the whole document. Therefore a document with an existing UniqueKey marks the old document as deleted and inserts the new one. However this is not the whole story, since this "constraint" only works per index/SolrCore/Shard (depending on your use-case).
Does this help you? Kind regards, Em Am 23.02.2012 15:34, schrieb 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 >> > Belive the uniqueKey does not enforce a "unique key constraint", so that > you are not allowed to create a document with an id's when an document > with the same id already exists. So it is not the whole solution. >> >>> 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 >>> >>> >> >> > >
