[
https://issues.apache.org/jira/browse/SOLR-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040472#comment-14040472
]
Umesh Prasad commented on SOLR-6168:
------------------------------------
Okay .. Here is my first attempt at this .. I am attaching this for comments
if I am going in right direction
Changes
1. Added two more implementations of FieldValueCollapse
ScoreValueCollapse for collapsing on score
StringValueCollapse for collapsing on global string ords.
2. Implemented CompositeValueCollapse,
It gets sorts params and creates an array of FieldValueCollapse , which it
calls in sequence.
3. collapse, returns NEXT_ACTION which can take ALIGN, BREAK or CONTINUE and
is used by CompositiveValueCollapse to enable stable sort.
4. Added updateOrd(int ord, int contextDoc, int globalDoc) ,so that composite
collapse can use to update its constituent ords.
The test cases pass mostly. However code is quite hacked as of now and there
are no tests for testing sorting on string. Sharing of ords[]/scores[] between
the different instances of FieldValueCollapse breaks encapsulation. I think
FieldValueCollapse can be better replaced with CollapasingComparator in line of
FieldComparator ..
> CollapsingQParserPlugin ranks incorrectly when 3 or more sort params are used
> -----------------------------------------------------------------------------
>
> Key: SOLR-6168
> URL: https://issues.apache.org/jira/browse/SOLR-6168
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.7.1, 4.8.1
> Reporter: Umesh Prasad
> Assignee: Joel Bernstein
> Attachments: CollapsingQParserPlugin-6168.patch.1-1stcut,
> SOLR-6168-group-head-inconsistent-with-sort.patch
>
>
> CollapsingQParser Plugin ranks documents incorrectly when more than 2 sort
> fields are used.
> I have attached a test case, which demonstrates the broken behavior when 3
> sort fields are used.
> The failing test case patch is against Lucene/Solr 4.8.1 revision number
> 1603061
> PS : SOLR-5408 fixed the issue with sorting only for two sort fields, by
> allowing one to specify max/min=<field-name>. However that requires 2nd sort
> field to be a numeric field. It will not work with string field or function
> query sort.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
