Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Wed, 23 May 2012 01:48:40 +0000 (UTC)
From: "Hoss Man (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <14187852.10297.1337737720858.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <754868962.37569.1331173977881.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-3215) We should clone the
 SolrInputDocument before adding locally and then send that clone to
 replicas.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Hoss Man commented on SOLR-3215:
--------------------------------

bq. Are there use cases for this?)

FWIW: the other use case that just occurred to me today is trying to use any update processors that deal with multiple field values (either existing processors people may have written, or any of the new ones added by SOLR-2802, or SOLR-2599) in conjunction with field updating (SOLR-139) which is implemented as part of the DistributedUpdateProcessor.

ie: if you want to have a multivalued "all_prices" field, and a single valued "lowest_price" field that you populate using a combination of CloneFieldUpdateProcessorFactory + MinFieldValueUpdateProcessorFactory -- that will need to happen after the DistributedUpdateProcessor in order to ensure all the values are available if someone does field update to "add" a value to "all_prices".


> We should clone the SolrInputDocument before adding locally and then send that clone to replicas.
> -------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-3215
>                 URL: https://issues.apache.org/jira/browse/SOLR-3215
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Mark Miller
>            Assignee: Mark Miller
>             Fix For: 4.0
>
>         Attachments: SOLR-3215.patch
>
>
> If we don't do this, the behavior is a little unexpected. You cannot avoid having other processors always hit documents twice unless we support using multiple update chains. We have another issue open that should make this better, but I'd like to do this sooner than that. We are going to have to end up cloning anyway when we want to offer the ability to not wait for the local add before sending to replicas.
> Cloning with the current SolrInputDocument, SolrInputField apis is a little scary - there is an Object to contend with - but it seems we can pretty much count on that being a primitive that we don't have to clone?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org