[jira] [Issue Comment Deleted] (SOLR-9783) remove no-longer-needed sortWithinGroup null checks in (Search|Top)Group[s]ShardResponseProcessor

["Judith Silverman (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-9783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Judith Silverman updated SOLR-9783:
-----------------------------------
    Comment: was deleted

(was: Hello, is there any context in which we *don't* want to interpret a null Sort value in a SortSpec as Sort.RELEVANCE?  I ask because I just had a test fail because sortWithinGroup was null. (My code is highly experimental, so this failure doesn't prove anything about the master.)  My investigation led me to SortSpecParsing's newEmptySortSpec(), which feeds a null Sort value to a SortSpec constructor.  I'm wondering whether newEmptySortSpec() could send Sort.RELEVANCE instead and/or the SortSpec constructors could be modified to replace nulls with Sort.RELEVANCE (and to adjust whatever else would need adjusting).  Apologies if this idea is impractical or has already been considered and dismissed.)

> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org