[
https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602745#action_12602745
]
Grant Ingersoll commented on SOLR-572:
--------------------------------------
{quote}
Grant - The exception is happening because the SpellCheckComponent always
passes Solr's own IndexReader when calling the
AbstractLuceneSpellChecker#getSuggestions method even when the underlying spell
checker is a FileBasedSpellChecker. In that case, since a non-null IndexReader
is passed onto Lucene, it tries to create a term on the null field name. That
is when the NullPointerException comes up.
{quote}
Yep, I think I fixed this piece. See also LUCENE-1299
{quote}
I think a possible solution can be to add another abstract method with the same
signature as Lucene's SpellChecker to the AbstractLuceneSpellChecker and let
each sub-class get suggestions on it's own. That way FileBasedSpellChecker will
pass the correct IndexReader or a null IndexReader into Lucene appropriately.
The AbstractLuceneSpellChecker#getSuggestion will just call the underlying
suggest method, get the String[] back and process as it does right now.
{quote}
Not sure I follow the solution (I understand the problem) Which signature are
you suggesting?
> 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, 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.