[
https://issues.apache.org/jira/browse/SOLR-11532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16220535#comment-16220535
]
Steve Rowe commented on SOLR-11532:
-----------------------------------
bq. It's a fair point that my proposal to have the optimizer consider
useDocValuesAsStored will expand the semantic scope of it... but I think it's a
fitting of this flag. If you disagree, then perhaps we can have the FieldType
more explicitly declare that the stored value should be used in preference to
the docValues value.
I'm okay with expanding uDVAS's semantic scope - just wanted to note it
explicitly.
bq. Notice useDocValuesAsStored doesn't say "wildcard" in its name I think of
it as... use docValues as stored if there is ambiguity. Ambiguity if for a
wildcard, but it's also for a field that has both stored & docValues.
+1
> 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, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
