[
https://issues.apache.org/jira/browse/SOLR-15047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-15047:
--------------------------------------
Attachment: SOLR-15047.patch
Status: Open (was: Open)
With SOLR-15048 fixed, fixing this now becomes straight forward, and we already
have a pretty decent test in place (just needed to switch switch one of the
group values to '0' to prove the test failed before these fixes, and passes
again with the changes in place)
> 'collapse' on numeric field treats all docs with '0' in collapse field as
> part of the null group
> ------------------------------------------------------------------------------------------------
>
> Key: SOLR-15047
> URL: https://issues.apache.org/jira/browse/SOLR-15047
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-15047.patch, SOLR-15047.patch
>
>
> The CollapseQParser has some very, _very_, old code/semantics in it that date
> back to when the {{FieldCache}} was incapable of differentiating between a
> document that contained '0' in the field being un-inverted, and a document
> that didn't have any value in that field.
> This limitation does not exist in DocValues (nor has it existed for a long
> time) but as the DocValues API has evolved, and as the collapse code has been
> updated to take advantage of the newer APIs that make it obvious when a
> document has no value in a field, the collapse code still explicitly equates
> "0" in a numeric field with the "null group"
> We can/should fix this bug so that the behavior is sane.
> ----
> Known workaround for this problem: (redundantly) index a "string" version of
> the field being collapsed on - but this is a poor substitute fro being able
> to efficiently collapse on numeric fields (which take up less space on disk
> and in the collapse data structures)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
