[
https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071106#comment-17071106
]
Eugene Tenkaev commented on SOLR-8030:
--------------------------------------
[~dsmiley] sorry don't have it, but this error may go from here
*AtomicUpdateDocumentMerger* which is used by *DistributedUpdateProcessor*.
Inside *AtomicUpdateDocumentMerger* have next code:
{code}
protected void doSet(SolrInputDocument toDoc, SolrInputField sif, Object
fieldVal) {
SchemaField sf = schema.getField(sif.getName());
toDoc.setField(sif.getName(), sf.getType().toNativeType(fieldVal));
}
protected void doAdd(SolrInputDocument toDoc, SolrInputField sif, Object
fieldVal) {
SchemaField sf = schema.getField(sif.getName());
toDoc.addField(sif.getName(), sf.getType().toNativeType(fieldVal));
}
{code}
and so on.
Try insert doc:
{code}
{
"id": 1,
"test": "ggg"
}
{code}
Error:
{code}
copyField dest :'test_str' is not an explicit field and doesn't match a
dynamicField.
{code}
We use post-processor that mentioned *after* *DistributedUpdateProcessor*.
> 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
