Spellcheck component not returned with numeric queries

Details

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.

Hoss Man
added a comment - 23/Mar/12 20:31 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

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)

Hoss Man
added a comment - 14/Jun/12 01:13 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)

Hoss Man
added a comment - 07/Sep/12 22:13 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)

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.

David Smiley
added a comment - 11/Jun/15 18:04 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.

James Dyer
added a comment - 02/Dec/15 20:12 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.