[
https://issues.apache.org/jira/browse/SOLR-11532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16219874#comment-16219874
]
Cao Manh Dat commented on SOLR-11532:
-------------------------------------
bq. I was thinking maybe your SolrDocumentFetcher.isDecorableDV() method should
belong on the Solr FieldType to thus give the FieldType the ability to elect a
choice? And of course named something like
canDocValueSubstituteForStoredIfHasBoth? I was thinking of a field type that
knew that despite being multiValued, it knows it's docValues is equivalent
(perhaps 'set' functionality). But then such an advanced user would then simply
not have the redundant stored field. So perhaps nevermind then; I just want to
share my thoughts.
I do not sure this is a good idea. There are couple of concerns here
- FieldType already has many many methods, it will be easy for someone to not
implement them and not all FieldType support encode field's value to DV.
- SolrDocumentFetcher is a central place to do the decoding from DV to field's
value. So I kinda feel this is the right place to put this method.
> 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
>
>
> 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]
