[ 
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to