[
https://issues.apache.org/jira/browse/SOLR-9783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706490#comment-15706490
]
Christine Poerschke commented on SOLR-9783:
-------------------------------------------
bq. ... to interpret a null Sort value in a SortSpec as ...
Yes, that's a good question as to if/how/why/when the Sort value in a SortSpec
might be null and if it is null, how to interpret that.
Within this change/ticket here I was just specifically looking at whether or
not the sortWithinGroup within a GroupingSpecification could ever be null at
the point at which the ...ShardResponseProcessor is using it. From my reading
of the code I concluded that it would never be null because of the
[QueryComponent.java#L249-L269|https://github.com/apache/lucene-solr/blob/bf9db95f218f49bac8e7971eb953a9fd9d13a2f0/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java#L249-L269]
logic.
bq. ... I'm wondering whether newEmptySortSpec() could send Sort.RELEVANCE
instead and/or the SortSpec constructors could be modified to replace nulls
with Sort.RELEVANCE ...
newEmptySortSpec() sending Sort.RELEVANCE instead of null sounds an interesting
idea. I wonder where else apart from QueryComponent.java#L249-L269 there is
"null means Sort.RELEVANCE" logic (or indeed "null means SomethingElse" logic)
that would go away if newEmptySortSpec() stopped sending null.
> remove no-longer-needed sortWithinGroup null checks in
> (Search|Top)Group[s]ShardResponseProcessor
> -------------------------------------------------------------------------------------------------
>
> Key: SOLR-9783
> URL: https://issues.apache.org/jira/browse/SOLR-9783
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Christine Poerschke
> Assignee: Christine Poerschke
> Priority: Minor
> Attachments: SOLR-9783.patch
>
>
> Why this, why now? I was looking some more at SOLR-6203 and what the next
> sub-step after the SOLR-9660 sub-step might be. Revisiting [~Judith]'s
> SOLR-6203 README file, the step (1) is included in SOLR-9660 and step (2)
> mentions passing around SortSpecs rather than plain Sorts, with Search and
> TopGroups ShardResponseProcessor amongst the files affected. In principle the
> change for those two files should be straightforward i.e.
> {code}
> ...
> - Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
> + SortSpec sortSpecWithinGroup =
> rb.getGroupingSpec().getSortSpecWithinGroup();
> ...
> {code}
> except that both starting points are
> {code}
> Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
> if (sortWithinGroup == null) { // TODO prevent it from being null in the
> first place
> sortWithinGroup = Sort.RELEVANCE;
> }
> {code}
> and so this ticket here aims to get rid of the two 'TODO' statements. The
> statements were added as part of LUCENE-6900's
> https://svn.apache.org/viewvc?view=revision&revision=1716569 in November 2015
> and Judith's original SOLR-6203.patch is from October 2015 i.e. slightly
> before then.
> [~dsmiley] - do you recall anything re: when/how {{sortWithinGroup}} could be
> null back then? From my reading of the current (master) code the
> sortWithinGroup would never be null now. {{solr/core}} tests pass when the if
> statements are removed (will attach patch and also run the non-core solr
> tests) but that could of course just be due to lacking test coverage.
> And unrelated but noticed whilst in the code area, the patch includes a
> {code}
> + ... || sort == Sort.RELEVANCE) {
> - ... || sort.equals(Sort.RELEVANCE)) {
> {code}
> tweak to QueryCommand.java also.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
