[
https://issues.apache.org/jira/browse/SOLR-9650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15580118#comment-15580118
]
Shawn Heisey commented on SOLR-9650:
------------------------------------
This probably should have been brought up on the mailing list or IRC channel
before going to Jira. I can understand why you would think it's a bug without
discussion, though.
Looking at the code for CloneFieldUpdateProcessorFactory, the order of the
fields in the configuration makes no difference.
For the Clone processor, the order of the fields in the SolrInputDocument
(AFTER it is received by Solr) is what matters. That class stores them in a
LinkedHashMap, which guarantees insertion order, but I do not know if there is
any guarantee that the SolrInputDocument built in SolrJ will be 100% identical
to the SolrInputDocument used by the update processor as far as field order.
That would depend on two things -- exactly how SolrJ packages the document for
transmission, and exactly how Solr treats the request when it receives it and
turns it back into a SolrInputDocument for update processing. I'm not very
familiar with that code. If a different map implementation (like HashMap) is
used at any point in that process, then field order might not be preserved.
You did say "fields are composed in order from SolrInputDocument" above ... but
that's vague. Can you share your SolrJ code, with \{code:java\} before it in
the comment, and \{code\} after it in the comment?
> CloneFieldUpdateProcessorFactory doesn't preserve source fields order from
> configuration
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-9650
> URL: https://issues.apache.org/jira/browse/SOLR-9650
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
> Affects Versions: 6.1
> Reporter: Libor Ondrusek
>
> We are using configuration like this:
> {code:xml}
> <!-- Creates a composite ID -->
> <updateRequestProcessorChain name="composite-id">
> <processor class="solr.CloneFieldUpdateProcessorFactory">
> <str name="source">_id</str>
> <str name="source">_validFrom</str>
> <str name="dest">_solrId</str>
> </processor>
> <processor class="solr.ConcatFieldUpdateProcessorFactory">
> <str name="fieldName">_solrId</str>
> <str name="delimiter">-</str>
> </processor>
> <processor class="solr.LogUpdateProcessorFactory" />
> <processor class="solr.RunUpdateProcessorFactory" />
> </updateRequestProcessorChain>
> {code}
> Expected {{_solrId}} field value for document
> {code:javascript}
> {
> "name": "Name",
> "_validFrom": 342230400000,
> "_validTo": null,
> "_id": "a518fad5-5421-4253-b501-0ebea0d32cd2"
> }
> {code}
> is *{{a518fad5-5421-4253-b501-0ebea0d32cd2-342230400000}}*
> When HTTP REST is used, everything work fine.
> When programmatics interface using {{SolrInputDocument}} in {{SolrClient}} is
> used value of {{_solrId}} will
> *{{342230400000-a518fad5-5421-4253-b501-0ebea0d32cd2}}* because fields are
> composed in order from {{SolrInputDocument}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
