lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shalin Shekhar Mangar (JIRA)" <>
Subject [jira] Commented: (SOLR-572) Spell Checker as a Search Component
Date Fri, 16 May 2008 13:17:55 GMT


Shalin Shekhar Mangar commented on SOLR-572:

Bojan -- Thanks for adding this functionality. I'll work on making things more configurable
like SCRH and add a few tests. I think it is OK and may even be needed for a few cases. Though
I prefer Noble's suggestion on having fieldType instead of field since it gives more freedom
to the user.

Grant -- Thanks for looking into the patch. My comments below:
# Right, those were generated by my IDE, I'll remove it in the next patch
# Agree
# Agree, both 2 and 3 are on my todo list
# I don't understand what you mean by "defer to others" but on making this default or not,
I'm fine either way.
# Actually, the spellChecker.getSuggestion(q, count) returns a complete named list, which
already has the numFound element. If you don't specify the count, then it gives back only
a String for which we need to create a NamedList ourselves. In other words, the response format
is actually the same both ways.

Noble -- I your suggestion on keeping a fieldType attribute in the configuration for non-Solr
dictionaries. We can use the QueryAnalyzer defined for the given fieldType in Solr's schema.
If this attribute is not present, we can default to WhitespaceAnalyzer or StandardAnalyzer.

> Spell Checker as a Search Component
> -----------------------------------
>                 Key: SOLR-572
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: spellchecker
>    Affects Versions: 1.3
>            Reporter: Shalin Shekhar Mangar
>             Fix For: 1.3
>         Attachments: 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.

View raw message