[
https://issues.apache.org/jira/browse/LUCENE-6486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14552347#comment-14552347
]
Michael McCandless commented on LUCENE-6486:
--------------------------------------------
[~mariusneo] OK thank you for digging, it sounds risky to return "null" for
payload and contexts since consumers don't expect that ... so let's just "cast"
missing -> empty for both payloads and contexts, like in your last patch.
On the new test case, it looks like testBasic just got renamed to
testWithOptionalPayload, with a few added checks?? Can you instead put
testBasic back and make a new very minimal testWithOptionalPayload? I was
picturing a tiny test case that indexes 1 doc (and does not use
generateIndexDocuments) that's missing its payload and then confirms it's an
empty BytesRef when iterating ... I think separate single-purpose test cases
are nicer than the all-encompassing testBasic seems to be...
> DocumentDictionary entry iterator skips items with optional null payload field
> ------------------------------------------------------------------------------
>
> Key: LUCENE-6486
> URL: https://issues.apache.org/jira/browse/LUCENE-6486
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 4.10.3
> Reporter: Marius Grama
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6486.patch, LUCENE-6486.patch, LUCENE-6486.patch
>
>
> As denoted in the ticket SOLR-7086 the DocumentDictionary entry iterator
> shouldn't skip entries from the dictionary having null value for the payload
> field due to the fact that this field is optional.
> This behaviour causes inconsistencies in the Solr suggester which simply
> skips valid documents due to the fact that they don't have values for the
> payload field.
> As agreed with [~mikemccand] I am attaching a patch to this Lucene issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
