[
https://issues.apache.org/jira/browse/SOLR-11532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218644#comment-16218644
]
Cao Manh Dat commented on SOLR-11532:
-------------------------------------
Thanks [~dsmiley]
bq. 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.
Thanks for the naming suggestion ( but I see a red line below work decoratable
:) ). I think that allSingleDv is only used by RetrieveFieldsOptimizer so there
is no problem in rename it. Yeah, the code looks not very nice, but could not
come up with better solution
bq. perhaps the multiValued check on SolrDocumentFetcher constructor line 123
belongs in the method isDecorableDV that you refactored out?
Yes, the method makes the boolean check easier to understand without having to
look into detail.
bq. in the catch around decorating docValues falling back on the stored value,
we ought to at least log at debug level?
Yeah, sure!
bq. 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)
Excellent suggestion
bq. you added the comment // The NumberType can be null but did nothing about
it when I think you intended to?
my idea here is adding a NumberType called Unknown, but did not sure about this.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
