Hoss Man created SOLR-5374:
------------------------------
Summary: 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
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
