[ https://issues.apache.org/jira/browse/SOLR-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yonik Seeley updated SOLR-5374: ------------------------------- Attachment: SOLR-5374.patch OK, here's the final patch with everything cleaned up, and with a new stress test and optimizations to use the fieldcache/docvalues when possible instead of always going to stored fields. > Support user configured doc-centric versioning rules > ---------------------------------------------------- > > Key: SOLR-5374 > URL: https://issues.apache.org/jira/browse/SOLR-5374 > Project: Solr > Issue Type: Improvement > Reporter: Hoss Man > Assignee: Hoss Man > Attachments: SOLR-5374.patch, SOLR-5374.patch, SOLR-5374.patch, > SOLR-5374.patch, SOLR-5374.patch > > > The existing optimistic concurrency features of Solr can be very handy for > ensuring that you are only updating/replacing the version of the doc you > think you are updating/replacing, w/o the risk of someone else > adding/removing the doc in the mean time -- but I've recently encountered > some situations where I really wanted to be able to let the client specify an > arbitrary version, on a per document basis, (ie: generated by an external > system, or perhaps a timestamp of when a file was last modified) and ensure > that the corresponding document update was processed only if the "new" > version is greater then the "old" version -- w/o needing to check exactly > which version is currently in Solr. (ie: If a client wants to index version > 101 of a doc, that update should fail if version 102 is already in the index, > but succeed if the currently indexed version is 99 -- w/o the client needing > to ask Solr what the current version) > The idea Yonik brought up in SOLR-5298 (letting the client specify a > {{\_new\_version\_}} that would be used by the existing optimistic > concurrency code to control the assignment of the {{\_version\_}} field for > documents) looked like a good direction to go -- but after digging into the > way {{\_version\_}} is used internally I realized it requires a uniqueness > constraint across all update commands, that would make it impossible to allow > multiple independent documents to have the same {{\_version\_}}. > So instead I've tackled the problem in a different way, using an > UpdateProcessor that is configured with user defined field to track a > "DocBasedVersion" and uses the RTG logic to figure out if the update is > allowed. -- This message was sent by Atlassian JIRA (v6.1#6144) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org