[
https://issues.apache.org/jira/browse/SOLR-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799957#comment-13799957
]
Mark Miller commented on SOLR-4937:
-----------------------------------
SOLR-5223 is now complete for 4.6 and JavaBin is used by SolrCloud to forward
around update requests.
> SolrCloud doesn't distribute null values
> ----------------------------------------
>
> Key: SOLR-4937
> URL: https://issues.apache.org/jira/browse/SOLR-4937
> Project: Solr
> Issue Type: Bug
> Reporter: Steve Davids
> Fix For: 4.6
>
>
> When trying to overwrite field values in SolrCloud using
> doc.setField(fieldName, null) it produces inconsistent behavior depending on
> the routing of the document to a specific shard. The binary format that is
> sent in preserves the null, but when the DistributedProcessor forwards the
> message to replicas it writes the message to XML using
> ClientUtils.writeVal(..) which drops any null value from the XML
> representation. This was especially problematic when a custom processor was
> initially placed after the distributed processor using the previously
> mentioned setField(null) approach but then moved ahead of the
> DistributedProcessor which no longer works as expected. It appears that I now
> need to updated the code to: doc.setField(fieldName,
> Collections.singletonMap("set", null)) for it to properly distribute
> throughout the cloud due to the XML restrictions. The fact that the custom
> processor needs to change depending on it's location in reference to the
> DistributedProcessor is a drag. I believe there should be a requirement that
> you can take a SolrInputDocument -> toXml -> toSolrInputDocument and assert
> that the two SolrInputDocuments are equivalent, instead of a lossy
> translation to XML.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
