[
https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070927#comment-17070927
]
Eugene Tenkaev edited comment on SOLR-8030 at 3/30/20, 12:24 PM:
-----------------------------------------------------------------
{quote}
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.
{quote}
Not able to do this, since I will receive error about that this field not
exists in schema, so this technical field should still be capable for normal
processing. But yes, as you mention, we will throw away this field in our
post-processor, so it will not go in index at the end.
So here summary from my side(as consumer) what helps us to solve this problem
at least for our particular case(removing specific set of dynamic fields *per
document* that was indexed previously):
1. Meta fields/parameters that will be in *SolrInputDocument* and will be saved
in *UpdateLog* (preferable). And later all post-processors in default chain in
any case should be able to see those meta fields/parameters
2. Request parameters that will be also saved along with info from
*SolrInputDocument* (for our case this looks mostly as workaround, but still
acceptable)
was (Author: hronom):
{quote}
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.
{quote}
Not able to do this, since I will receive error about that this field not
exists in schema, so this technical field should still be capable for normal
processing. But yes, as you mention, we will throw away this field in our
post-processor, so it will not go in index at the end.
So here summary from my side(as consumer) what helps us to solve this problem
at least for our particular case(removing specific set of dynamic fields that
was indexed previously):
1. Meta fields/parameters that will be in *SolrInputDocument* and will be saved
in *UpdateLog* (preferable). And later all post-processors in default chain in
any case should be able to see those meta fields/parameters
2. Request parameters that will be also saved along with info from
*SolrInputDocument*
> 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
