[
https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798787#comment-15798787
]
Hoss Man commented on SOLR-8030:
--------------------------------
bq. The point is that for main operations, the Document Update Processors do
not have access to the Solr request.
I'm not sure what you mean by that -- during normal update processing the
SolrQueryRequest is available to UpdateProcessorFactories as part of the
{{getInstance(...)}} call as well as to the UpdateProcessors themselves via
{{UpdateCommand.getReq()}} and some factories/processors (like
StatelessScriptUpdateProcessorFactory in my example) access the request to get
the request params and make conditional choices based on those values -- but
unless i'm completely missing something, things like the request params are not
written to the tlog when the UpdateCommands are written to the tlog.
hence: the scope of the problem goes beyond just keeping a record of the update
chain needed for each command in the tlog, it's a matter of tracking _ALL_ the
relevant variables (chain, req params, etc...)
bq. But I do not agree with [~dsmiley] that this should not be fixed because of
very specific use cases.
I suspect you missunderstood david -- either that or i did -- i don't think
he's of the opinion that this shouldn't be fixed, my understanding of his
comments is that:
* he agrees the entire situation is bad, and should fixed in some way
* he would rather look a the big picture and "rip the bandaid off" with
whatever sort of invasive fix is needed then add more band-aids on top of the
code we already have
* until such time as we have a "good" fix, the workaround is to encourage
people to only use chains/updates that _will_ work in spite of this bug.
i would agree with those three sentiments, even if they aren't what he actually
ment :)
> 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
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
