Hi Geoffrey, Yes, this is a caveat in the lucene contrib spellchecker which Solr uses. >From the lucene spell checker javadocs:
* <p>As the Lucene similarity that is used to fetch the most relevant n-grammed terms * is not the same as the edit distance strategy used to calculate the best * matching spell-checked word from the hits that Lucene found, one usually has * to retrieve a couple of numSug's in order to get the true best match. * * <p>I.e. if numSug == 1, don't count on that suggestion being the best one. * Thus, you should set this value to <b>at least</b> 5 for a good suggestion. Therefore what you're seeing is by design. Probably we should change the default number of suggestions when querying lucene spellchecker to 5 and give back the top result if the user asks for only one suggestion from solr. On Wed, Apr 23, 2008 at 5:58 PM, Geoffrey Young <[EMAIL PROTECTED]> wrote: > hi :) > > I've noticed that (with solr 1.2) the returned order (as well as the > actual matched set) is affected by the number of matches you ask for: > > q=hanna&suggestionCount=1 > "suggestions":["Yanna"] > > q=hanna&suggestionCount=2 > "suggestions":["Manna", > "Yanna"] > > q=hanna&suggestionCount=5 > "suggestions":["Manna", > "Nanna", > "Sanna", > "Vanna", > "Shanna"] > > note how the "#1" result is completely missing from the "top 5"... or at > least that's how I _used_ to think about the sets :) > > unfortunately, extendedresults seems to be a 1.3-only option, so I can't > see what's going on here. but I guess I'm asking if this is expected > behavior. > > --Geoff > -- Regards, Shalin Shekhar Mangar.