[
https://issues.apache.org/jira/browse/SOLR-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13415861#comment-13415861
]
Lance Norskog commented on SOLR-3215:
-------------------------------------
Can I suggest the concept of a "preprocessed" or "flattened" or "read-only"
document?
Each processor would have the responsibility to say "I only changed
un-flattened documents". After all, update processors can also do things like
logging- it would not be ok to skip the logger just because it is above the
DistributedProcessor stage.
If you want, you can add a marker interface for "I alter documents" and the
update process chain handler can skip these.
> 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
> Priority: Minor
> 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]
