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

Yonik Seeley commented on SOLR-3215:
------------------------------------

Not sure I understand the problem this is solving.  _version_ is added to the 
SolrInputDocument and then that can be indexed locally and sent to replicas.  
DistributedUpdateProcessor should come right before RunUpdateProcessor (or are 
you assuming we might support random update processors in-between? Are there 
use cases for this?)
                
> 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to