lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (SOLR-5374) Support user configured doc-centric versioning rules
Date Sat, 09 Nov 2013 15:58:18 GMT


ASF subversion and git services commented on SOLR-5374:

Commit 1540336 from [] in branch 'dev/trunk'
[ ]

SOLR-5374: missing returns in user versioning processor

> Support user configured doc-centric versioning rules
> ----------------------------------------------------
>                 Key: SOLR-5374
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>             Fix For: 4.6, 5.0
>         Attachments: SOLR-5374.patch, 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
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message