Solr
  1. Solr
  2. SOLR-2556

Spellcheck component not returned with numeric queries

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 5.5
    • Component/s: spellchecker
    • Labels:
      None

      Description

      The spell check component's output is not written when sending queries that
      consist of numbers only. Clients depending on the availability of the
      spellcheck output need to check if the output is actually there.

      See also:
      http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3C201105301607.41956.markus.jelsma@openindex.io%3E

      1. SOLR-2556.patch
        3 kB
        James Dyer
      2. SOLR-2556.patch
        2 kB
        James Dyer

        Activity

        Hide
        Robert Muir added a comment -

        3.4 -> 3.5

        Show
        Robert Muir added a comment - 3.4 -> 3.5
        Hide
        Hoss Man added a comment -

        Bulk changing fixVersion 3.6 to 4.0 for any open issues that are unassigned and have not been updated since March 19.

        Email spam suppressed for this bulk edit; search for hoss20120323nofix36 to identify all issues edited

        Show
        Hoss Man added a comment - Bulk changing fixVersion 3.6 to 4.0 for any open issues that are unassigned and have not been updated since March 19. Email spam suppressed for this bulk edit; search for hoss20120323nofix36 to identify all issues edited
        Hide
        Hoss Man added a comment -

        when i read this issue, i assumed it was simply a matter of the spellcheck response block not being included if there was no suggestions, but it's more subtle then that.

        These queries don't produce any spellcheck section in the response at all...

        But these queries do (even if that section contains no suggestions)....

        Note in particular that last one - using "spellcheck.q=9999" causes the empty section to appear, even if it's identical to "q=9999"

        Skimming the code, the problem seems to relate to the user of the "queryConverter", and the fact that it's only used on the "q" param (a different code path is used on the "spellcheck.q" param) and what happens if no tokens are produced – the "spellcheck" block is added to the response inside a conditional block that is only executed if there are tokens.

        It seems like it would be fairly easy to just move the code that adds the block to the response outside of the conditional – but the fact that the two code paths produce different behavior makes me wonder if this isn't semi-intentional? is the idea that "your query converter produced no tokens, therefore we assume you don't want any spellcheck results?" should it be?

        (FWIW: there is a similar condition where no "spellcheck" response is generated if there are no dictionaries configured)

        Show
        Hoss Man added a comment - when i read this issue, i assumed it was simply a matter of the spellcheck response block not being included if there was no suggestions, but it's more subtle then that. These queries don't produce any spellcheck section in the response at all... http://localhost:8983/solr/spell?debugQuery=true&q=1&spellcheck=true&spellcheck.collate=true&spellcheck.build=true http://localhost:8983/solr/spell?debugQuery=true&q=9999&spellcheck=true&spellcheck.collate=true&spellcheck.build=true But these queries do (even if that section contains no suggestions).... http://localhost:8983/solr/spell?debugQuery=true&q=______&spellcheck=true&spellcheck.collate=true&spellcheck.build=true http://localhost:8983/solr/spell?debugQuery=true&q=asfasdfasdfasdfasdf&spellcheck=true&spellcheck.collate=true&spellcheck.build=true http://localhost:8983/solr/spell?debugQuery=true&spellcheck.q=9999&q=9999&spellcheck=true&spellcheck.collate=true&spellcheck.build=true Note in particular that last one - using "spellcheck.q=9999" causes the empty section to appear, even if it's identical to "q=9999" Skimming the code, the problem seems to relate to the user of the "queryConverter", and the fact that it's only used on the "q" param (a different code path is used on the "spellcheck.q" param) and what happens if no tokens are produced – the "spellcheck" block is added to the response inside a conditional block that is only executed if there are tokens. It seems like it would be fairly easy to just move the code that adds the block to the response outside of the conditional – but the fact that the two code paths produce different behavior makes me wonder if this isn't semi-intentional? is the idea that "your query converter produced no tokens, therefore we assume you don't want any spellcheck results?" should it be? (FWIW: there is a similar condition where no "spellcheck" response is generated if there are no dictionaries configured)
        Hide
        Hoss Man added a comment -

        bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment

        Show
        Hoss Man added a comment - bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment
        Hide
        Robert Muir added a comment -

        rmuir20120906-bulk-40-change

        Show
        Robert Muir added a comment - rmuir20120906-bulk-40-change
        Hide
        Hoss Man added a comment -

        removing fixVersion=4.0 since there is no evidence that anyone is currently working on this issue. (this can certainly be revisited if volunteers step forward)

        Show
        Hoss Man added a comment - removing fixVersion=4.0 since there is no evidence that anyone is currently working on this issue. (this can certainly be revisited if volunteers step forward)
        Hide
        David Smiley added a comment -

        I've been investigating this oddity in an app I'm working on and found this issue here. I agree with Hoss's assessment – I have the same conclusions. If the current behavior is "semi-intentional", it isn't clear it should be; we could ask about the wisdom to James Dyer?. IMO, FWIW, this is a bug. Other components, when enabled (e.g. facet=on), output something; it's disconcerting to see nothing from spellcheck from time to time, and makes client parsing code more error prone (didn't expect a null). I may have time to fix this soon-ish.

        Show
        David Smiley added a comment - I've been investigating this oddity in an app I'm working on and found this issue here. I agree with Hoss's assessment – I have the same conclusions. If the current behavior is "semi-intentional", it isn't clear it should be; we could ask about the wisdom to James Dyer ?. IMO, FWIW, this is a bug. Other components, when enabled (e.g. facet=on), output something; it's disconcerting to see nothing from spellcheck from time to time, and makes client parsing code more error prone (didn't expect a null). I may have time to fix this soon-ish.
        Hide
        James Dyer added a comment -

        This looks like a bug to me.

        Show
        James Dyer added a comment - This looks like a bug to me.
        Hide
        James Dyer added a comment -

        Here is a patch with just failing unit tests.

        I think the best way to fix this is to make SpellingQueryConverter more robust to recognize digits as terms subject to corrections / suggestions.

        I do think the complete absence of the spellcheck section on the response was probably by design. If there are no terms in the query that can be corrected, it leaves it off altogether.

        Show
        James Dyer added a comment - Here is a patch with just failing unit tests. I think the best way to fix this is to make SpellingQueryConverter more robust to recognize digits as terms subject to corrections / suggestions. I do think the complete absence of the spellcheck section on the response was probably by design. If there are no terms in the query that can be corrected, it leaves it off altogether.
        Hide
        James Dyer added a comment -

        Here is a patch the tests passing. If everything checks out, I'll commit this tomorrow.

        Show
        James Dyer added a comment - Here is a patch the tests passing. If everything checks out, I'll commit this tomorrow.
        Hide
        ASF subversion and git services added a comment -

        Commit 1717795 from jdyer@apache.org in branch 'dev/trunk'
        [ https://svn.apache.org/r1717795 ]

        SOLR-2556: Fix SpellingQueryConverter to recognize terms consisting only of digits

        Show
        ASF subversion and git services added a comment - Commit 1717795 from jdyer@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1717795 ] SOLR-2556 : Fix SpellingQueryConverter to recognize terms consisting only of digits
        Hide
        ASF subversion and git services added a comment -

        Commit 1717796 from jdyer@apache.org in branch 'dev/branches/branch_5x'
        [ https://svn.apache.org/r1717796 ]

        SOLR-2556: Fix SpellingQueryConverter to recognize terms consisting only of digits

        Show
        ASF subversion and git services added a comment - Commit 1717796 from jdyer@apache.org in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1717796 ] SOLR-2556 : Fix SpellingQueryConverter to recognize terms consisting only of digits

          People

          • Assignee:
            James Dyer
            Reporter:
            Markus Jelsma
          • Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development