Solr
  1. Solr
  2. SOLR-2491

spellcheck.maxCollationTries breaks when using FieldCollapsing

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 4.0-ALPHA
    • Fix Version/s: 4.0-ALPHA
    • Component/s: spellchecker
    • Labels:
      None

      Description

      If specifying "spellcheck.maxCollationTries" and "group=true" on the same query, you never get any Spell Check Collations back. The problem is that SpellCheckCollator relies on ResponseBuilder.getToLog().get("hits") to see how many results each test query returns. When "group=true", the "toLog" isn't populated so SpellCheckCollator is unable to find a collation that can return results.

        Issue Links

          Activity

          Hide
          James Dyer added a comment -

          This patch fixes the problem & includes a unit test. This patch simply removes the "group" parameter from any test queries prior to running them.

          Note that the # of hits for each collation returned will always be the # of ungrouped hits. This is consistent with the fact that FieldCollapsing is unable to tell us the number of grouped hits.

          It is a bit disturbing to me how brittle getting the # of hits back via "toLog" has proven to be. If someone can point to a less breakable way to do this it would be appreciated.

          Show
          James Dyer added a comment - This patch fixes the problem & includes a unit test. This patch simply removes the "group" parameter from any test queries prior to running them. Note that the # of hits for each collation returned will always be the # of ungrouped hits. This is consistent with the fact that FieldCollapsing is unable to tell us the number of grouped hits. It is a bit disturbing to me how brittle getting the # of hits back via "toLog" has proven to be. If someone can point to a less breakable way to do this it would be appreciated.
          Hide
          Robert Muir added a comment -

          James: any opinion on this with regards to SOLR-2564?

          I'm totally lost when it comes to grouping, but do you still think collation should use ungrouped queries or should we wait on SOLR-2564, which seems to suggest it can return this count... I could be confused here and haven't looked in detail though.

          Show
          Robert Muir added a comment - James: any opinion on this with regards to SOLR-2564 ? I'm totally lost when it comes to grouping, but do you still think collation should use ungrouped queries or should we wait on SOLR-2564 , which seems to suggest it can return this count... I could be confused here and haven't looked in detail though.
          Hide
          James Dyer added a comment -

          I think this issue can go separately from SOLR-2564 and have it use ungrouped queries. This little patch allows people to use both features in tandem now rather than waiting for later (for instance, I have an app in production using this patch now...) .

          As a follow-up to SOLR-2564, it would be nice to give the user the option to return # of grouped hits. If the end-user is receiving groups as results and the app gives a message like "300 results (groups) returned", then in the case of a misspelled query, any "did-you-mean" message that includes # of hits would probably need to be consistent and give # groups rather than # documents. So this would be useful additional functionality, whenever we indeed get grouping that can return # groups...

          Maybe a separate issue should be opened just for this, and it can be worked after SOLR-2564 goes in?

          Show
          James Dyer added a comment - I think this issue can go separately from SOLR-2564 and have it use ungrouped queries. This little patch allows people to use both features in tandem now rather than waiting for later (for instance, I have an app in production using this patch now...) . As a follow-up to SOLR-2564 , it would be nice to give the user the option to return # of grouped hits. If the end-user is receiving groups as results and the app gives a message like "300 results (groups) returned", then in the case of a misspelled query, any "did-you-mean" message that includes # of hits would probably need to be consistent and give # groups rather than # documents. So this would be useful additional functionality, whenever we indeed get grouping that can return # groups... Maybe a separate issue should be opened just for this, and it can be worked after SOLR-2564 goes in?
          Hide
          Robert Muir added a comment -

          James: sounds like a plan.

          Lets try to get this one resolved and we can followup with the option (and maybe change default or whatever) when that makes sense.

          I'll review the patch shortly.

          Show
          Robert Muir added a comment - James: sounds like a plan. Lets try to get this one resolved and we can followup with the option (and maybe change default or whatever) when that makes sense. I'll review the patch shortly.
          Hide
          Robert Muir added a comment -

          Committed revision 1133043.

          Thanks James!

          Show
          Robert Muir added a comment - Committed revision 1133043. Thanks James!
          Hide
          Christian Johnsson added a comment -

          Hi, I wonder if this is also a bug: https://issues.apache.org/jira/browse/SOLR-3758
          Or if i have missunderstood something. Worked perfectly in 3.5 but not i 4.0 beta.

          Sorry for hijacking but i think it's kind of rellated

          Show
          Christian Johnsson added a comment - Hi, I wonder if this is also a bug: https://issues.apache.org/jira/browse/SOLR-3758 Or if i have missunderstood something. Worked perfectly in 3.5 but not i 4.0 beta. Sorry for hijacking but i think it's kind of rellated

            People

            • Assignee:
              Robert Muir
              Reporter:
              James Dyer
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development