[
https://issues.apache.org/jira/browse/SOLR-11532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218552#comment-16218552
]
David Smiley commented on SOLR-11532:
-------------------------------------
Interesting -- I like your approach [~caomanhdat].
* the wording "decorable" is not quite right, should be "decoratable". But
besides, this, "allSingleDV" becoming "allSingleDecoratableDV" seems
suspiciously troubling of some code quality concerns here... I'll think about
this more and suggest something more specific, and it's not going to be just
about some variable name.
* perhaps the multiValued check on SolrDocumentFetcher constructor line 123
belongs in the method isDecorableDV that you refactored out?
* in the catch around decorating docValues falling back on the stored value, we
ought to at least log at debug level?
* in that same method {{decorateDocValueFields}}, perhaps move the lines of
code preceding the try-statement that fetch the schemaField & FieldInfo into
the refactored method you extracted {{decorateDocValueField}} to reduce the
number of parameters by two? Seeing many method parameters is a code smell.
Perhaps {{decorateDocValueField}} should not actually set the field value but
instead return a potentially null value that the caller sets (and can thus
decide if null then don't replace with former value if it was non-null)
* you added the comment {{// The NumberType can be null}} but did nothing about
it when I think you intended to?
> 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
>
>
> 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]
