[
https://issues.apache.org/jira/browse/SOLR-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-5374:
---------------------------
Attachment: SOLR-5374.patch
Here's an initial patch with some basic docs and tests. There's some nocommits
I'm working on regarding configuration validation, and a few TODOs (that i'm
less immediately concerned with) related to seeing if I/we can't figure out
more efficient ways to do things.
The basic idea is that at a minimum the user configures a "versionField" which
the user can configure to be anything they want, and any time an AddDoc comes
in the processor rejects the add if the doc already exists and the value of the
new "versionField" isn't greater then the existing value.
There is also some optional code that can be configured to tell the processor
to apply the same rules to deleteById commands using a configured
"deleteVersionParam" request param name -- if the delete should succeed, then
it's actually replaced by an AddDoc that indexes an empty placeholder doc to
track the version of the delete so any subsequent "out of order" AddDoc can be
rejected.
Lastly: there's an optional "ignoreOldUpdates" config option, that causes the
processor to silently ignore (and return status=200) any updates whose version
is too low, instead of returning status=409 (Version Conflict)
> 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
>
>
> 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
