[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600524#action_12600524 ]
Grant Ingersoll commented on SOLR-572: -------------------------------------- {quote} Grant, unless I'm mistaken, the reason to add spellcheck.q parameter was to avoid the tedious query parsing logic that may be needed to extract "spellcheckable" terms from the q parameter. Do we really need to do this? All the extra things in the q parameter are usually added by the frontend itself, isn't it? {quote} Is that practical? How would an application even know how to generate spellcheck.q without parsing, etc.? I think the component should just work on the input query. I guess I hadn't really thought about the need for spellcheck.q before, but now that you put it in that light, I am not sure I see the need for it. I don't think all the extra things are necessarily added by the application. Users can input range queries, etc. The point is, it all depends on the application. At any rate, it is trivial to override the SpellingQueryConverter to not do the original REGEX and just apply the analyzer to produce the tokens. I suppose, we could offer two converters, one w/ the regex, and one without, or it could just have a flag. > Spell Checker as a Search Component > ----------------------------------- > > Key: SOLR-572 > URL: https://issues.apache.org/jira/browse/SOLR-572 > Project: Solr > Issue Type: New Feature > Components: spellchecker > Affects Versions: 1.3 > Reporter: Shalin Shekhar Mangar > Assignee: Grant Ingersoll > Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch > > > Expose the Lucene contrib SpellChecker as a Search Component. Provide the > following features: > * Allow creating a spell index on a given field and make it possible to have > multiple spell indices -- one for each field > * Give suggestions on a per-field basis > * Given a multi-word query, give only one consistent suggestion > * Process the query with the same analyzer specified for the source field and > process each token separately > * Allow the user to specify minimum length for a token (optional) > Consistency criteria for a multi-word query can consist of the following: > * Preserve the correct words in the original query as it is > * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.