[
https://issues.apache.org/jira/browse/SOLR-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-6168:
---------------------------
Attachment: SOLR-6168.patch
bq. Does it make sense to include SOLR-6345 in this work?
I don't think so?
# Nothing about this improvement relates to faceting or tagging/excluding, nor
should any of the changes impact any existing code related to the
faceting/tagging/excluding (unless i'm missing something, that's all external
to the implemenation of the CollapseFilter)
# SOLR-6345 doesn't even seem to even have an identified root cause, so trying
to fold in a fix for that with this issue seems like it would just
unneccessarily stall this improvement.
----
Updated patch...
* added randomized test coverage of nullPolicy + sort localparam
* updated randomized test with a (verification) work around for SOLR-8082
* added testing of sort param with elevation componanet
* added error checking + tests for tying to use more then one of min/max/sort
localparams
* made all of CollapsingQParserPlugin's nested classes static
** not specific to this issue, but a worthwhile code cleanup -- there was no
reason for them not to be static before and it was really bugging me while
reading/debugging
* created a new GroupHeadSelector class to encapsulate min vs max vs sort
options
** refactored existing code to pass down GroupHeadSelector instances instead of
"String min|max" and "boolean max" args
* cleanedup & refactored the needsScores init logic to use existing helper
methods in ReturnFields & SortSpec and fixed it to ensure the IndexSearcher
flag would always be set
** solves the case of a 'sort' local parmam needing scores even nothing about
top level request does (ie: no scores used in top sort or fl)
* refactored existing "cscore" init logic into a helper method that inspects
GroupHeadSelector
...that last bit of refactoring was done with the intention of re-using the
cscore method/logic to suport (group head selecting) Sorts that included a
function which include/wrap "cscore()" ... but the basic tests i'd tried to
write to cover this case didn't work, and the more i looked into it and thought
about it i realized this is actualy very tricky. The way "Sort" objects are
rewritten relative to a Searcher delegates the rewriting to each individual
SortField. If a SortField is rewritable, then it internally does it's
rewriting _and constructs a new clean (Map) context_ in the individual
SortField clauses. Even if we wanted to keep track of all the maps from every
SortField and put the same CollapseScore object in them, there's no
uniform/generic way to access those context Maps from an arbitrary SortField.
I don't have any clean sollutions in mind, so for now i've punted on this and
made the code throw an explicit error if you try to use "cscore()" with the
sort local param.
I think this patch is pretty much ready to go, but i want to sleep on it and
give it at least one more full read through before committing.
> enhance collapse QParser so that "group head" documents can be selected by
> more complex sort options
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-6168
> URL: https://issues.apache.org/jira/browse/SOLR-6168
> Project: Solr
> Issue Type: Improvement
> 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, SOLR-6168.patch,
> SOLR-6168.patch, SOLR-6168.patch, SOLR-6168.patch
>
>
> The fundemental goal of this issue is add additional support to the
> CollapseQParser so that as an alternative to the existing min/max localparam
> options, more robust sort syntax can be used to sort on multiple criteria
> when selecting the "group head" documents used to represent each collapsed
> group.
> Since support for arbitrary, multi-clause, sorting is almost certainly going
> to require more RAM then the existing min/max functionaly, this new
> functionality should be in addition to the existing min/max localparam
> implementation, not a replacement of it.
> (NOTE: early comments made in this jira may be confusing in historical
> context due to the way this issue was originally filed as a bug report)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
