Hi James/Robert, Thanks for the responses.
Robert: What is it about the current APIs that makes this hard? How much/what kind of refactoring would open this up? James: I didn't quite understand the usage you suggested. I thought that the spellcheck.q param shouldn't include field names, etc and that the purpose of specifying this param is to avoid the extra parsing out of the field names, etc. from the q param to get the query terms for spell checking. This is based on this bit in the SpellCheckComponent wiki - " The spellcheck.q parameter is intended to be the original query, minus any extra markup like field names, boosts, etc." Did I misunderstand something? I agree that it's impossible to know if the query "run" should be corrected to "sun" or "running" in the example I gave but I guess I'm asking more from the angle of how to avoid correcting terms that will be matched because they exist in other more processed fields that are being searched. Since the recommendation is to build spellcheck fields from minimally processed source fields, seems like this would be a common problem? And another kind of unrelated question - all the examples of spellcheck dictionaries I've seen in sample solrconfig.xmls have minPrefix set to 1. Is this for performance reasons? And with this setting, we wouldn't get "run" as a correction for "eon" right? Thanks, Nalini On Wed, Mar 7, 2012 at 11:04 AM, Robert Muir <rcm...@gmail.com> wrote: > On Wed, Jan 25, 2012 at 12:55 PM, Nalini Kartha <nalinikar...@gmail.com> > wrote: > > > > Is there any reason why Solr doesn't support using multiple spellcheckers > > for a query? Is it because of performance overhead? > > > > Thats not the case really, see > https://issues.apache.org/jira/browse/SOLR-2926 > > I think the issue is that the spellchecker APIs need to be extended to > allow this to happen easier, there is no real hard > performance/technical/algorithmic issue, its just a matter of > refactoring spellchecker APIs to allow this! > > -- > lucidimagination.com >
