[
https://issues.apache.org/jira/browse/SOLR-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802028#comment-13802028
]
Hoss Man commented on SOLR-5374:
--------------------------------
bq. it might not always be practical in a distributed system to have a version
ordering across updates as it's likely to involve a single point of coordination
Ramkumar: I'm not sure i understand your comment. The specific use case i'm
targeting here is precisely the situation where there is already a an
externally generated, per-document, version that we want to use to enforce that
only "new" updates are processed. see the issue description:
{panel}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) ...{panel}
bq. In such cases, it might just suffice for the system if the versions were
just equality comparable rather than having a strict ordering – i.e. update if
the previous version equals what I expect, else reject the update
What you are describing sounds like what is already possible using Solr's
existing optimistic concurrency features...
https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents#UpdatingPartsofDocuments-OptimisticConcurrency
I'm trying to address use cases i've seen come up recently where the client app
doesn't want to have to check, or keep track of, what's version is in the
_index_ (in several cases because they are already keeping track in an
independent authoritative data store) they just wants to add/replace a document
only if it's "newer" then whatever version is currently in the index.
> 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: [email protected]
For additional commands, e-mail: [email protected]
