[
https://issues.apache.org/jira/browse/SOLR-11532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16220436#comment-16220436
]
David Smiley commented on SOLR-11532:
-------------------------------------
Overall, looks improved Dat.
* I think the multiValued condition should move to the method
{{canSubstituteDvForStored(...}}}, in addition to checking that the field be
stored. Adding that it be stored isn't strictly necessary but reduces needless
entries in the set.
* {{decorateDocValueFields}}
** javadocs are wrong or confusing. "The list of docValues fields to be
decorated". As I understand it, we're decorating the _documents_ with the
fields, but as written you suggest the fields themselves are to be decorated.
Can we not use this "decorated" terminology please? We're simply fetching the
value from docValues, decoding/converting it to the right object type, and
putting it on the document :-)
** You've logged a warning "Couldn't decode docValues for field: \[\{\}\]" when
decodeDVField returns not-null. But this is incorrect; it's inverted -- we
*did* get a value. And even if we didn't, it's not necessarily a problem --
their might be no value for this field on this particular document. So in
summary, just remove the warning.
** can't the remove then addField be replaced with simply setField ?
> Solr hits NPE when fl only contains DV fields and any of them is a spatial
> field
> --------------------------------------------------------------------------------
>
> Key: SOLR-11532
> URL: https://issues.apache.org/jira/browse/SOLR-11532
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: spatial
> Affects Versions: 7.1
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
> Attachments: SOLR-11532-test.patch, SOLR-11532.patch,
> SOLR-11532.patch, SOLR-11532.patch
>
>
> Right now, Solr does not know how to decode DV value of
> LatLonPointSpatialField. Therefore, Solr will hit NPE when trying to do that,
> for example:
> - when fl contains a spatial field and it is DV + not stored
> - when fl only contains DV fields and any of them is a spatial field ( stored
> + DV ). Because SOLR-8344 will always use values from DV fields. This seems a
> common case.
> Stacktrace (from Solr 7.1)
> {code}
> 2017-10-23 10:28:52,528 [qtp1649011739-67] ERROR HttpSolrCall -
> null:java.lang.NullPointerException
> at
> org.apache.solr.search.SolrDocumentFetcher.decorateDocValueFields(SolrDocumentFetcher.java:525)
> at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:108)
> at org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)
> at
> org.apache.solr.response.BinaryResponseWriter$Resolver.writeResultsBody(BinaryResponseWriter.java:126)
> at
> org.apache.solr.response.BinaryResponseWriter$Resolver.writeResults(BinaryResponseWriter.java:145)
> at
> org.apache.solr.response.BinaryResponseWriter$Resolver.resolve(BinaryResponseWriter.java:89)
> at
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:239)
> at
> org.apache.solr.common.util.JavaBinCodec.writeNamedList(JavaBinCodec.java:223)
> at
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:330)
> at
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:228)
> at org.apache.solr.common.util.JavaBinCodec.marshal(JavaBinCodec.java:155)
> {code}
> This bug found by [~kiranch].
> The only solution for this problem is adding a stored field only in fl.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
