[
https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070623#comment-17070623
]
David Smiley commented on SOLR-8030:
------------------------------------
bq. Is there possibility that somehow code here will not work during replay and
we loose behavior that adds this processor?
Yes, sadly, because the original request params are not present in the update
log during replay.
bq. (Workaround:) add special technical field in schema
Yes, you could do something like that. I actually wouldn't touch the schema;
instead your URP will remove this meta field after it applies the logic to the
document.
bq. is it possible to move routing code out from DistributedUpdateProcessor
I'd argue routing is very much the job of this URP considering it's name :-)
Instead, as indicated in your last sentence, I think Atomic update processing
could be separated out. That'd be wonderful for maintainability as well I
think; DURP is a complex beast. However, Atomic update processing would be
logically done after the DURP and thus would be subject to the same conundrum
of this issue -- no access to the original request params. So this doesn't
solve your problem.
> Transaction log does not store the update chain (or req params?) used for
> updates
> ---------------------------------------------------------------------------------
>
> Key: SOLR-8030
> URL: https://issues.apache.org/jira/browse/SOLR-8030
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 5.3
> Reporter: Ludovic Boutros
> Priority: Major
> Attachments: SOLR-8030.patch
>
>
> Transaction Log does not store the update chain, or any other details from
> the original update request such as the request params, used during updates.
> Therefore tLog uses the default update chain, and a synthetic request, during
> log replay.
> If we implement custom update logic with multiple distinct update chains that
> use custom processors after DistributedUpdateProcessor, or if the default
> chain uses processors whose behavior depends on other request params, then
> log replay may be incorrect.
> Potentially problematic scenerios (need test cases):
> * DBQ where the main query string uses local param variables that refer to
> other request params
> * custom Update chain set as {{default="true"}} using something like
> StatelessScriptUpdateProcessorFactory after DUP where the script depends on
> request params.
> * multiple named update chains with diff processors configured after DUP and
> specific requests sent to diff chains -- ex: ParseDateProcessor w/ custom
> formats configured after DUP in some special chains, but not in the default
> chain
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
