Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 31 Oct 2013 21:49:19 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12674909.1382393545386.3578.1383256159504@arcas>
In-Reply-To: <JIRA.12674909.1382393545386@arcas>
References: <JIRA.12674909.1382393545386@arcas>
Subject: [jira] [Commented] (SOLR-5374) Support user configured doc-centric
 versioning rules
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810747#comment-13810747 ] 

ASF subversion and git services commented on SOLR-5374:
-------------------------------------------------------

Commit 1537706 from [~yonik@apache.org] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1537706 ]

SOLR-5374: fix unnamed thread pool

> 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
>             Fix For: 4.6, 5.0
>
>         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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org