lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Dyer (JIRA)" <>
Subject [jira] [Updated] (SOLR-2571) IndexBasedSpellChecker "thresholdTokenFrequency" fails with a ClassCastException on startup
Date Mon, 06 Jun 2011 15:24:58 GMT


James Dyer updated SOLR-2571:

    Attachment: SOLR-2571.patch

This version takes all of DirectSolrSpellChecker's parameters as Integer and Float objects
rather than Strings, as appropriate.  Also, I changed the "accuracy" parameter to use SpellingParams.SPELLCHECK_ACCURACY
... I'm not sure if this would have validated any unit tests (I didn't see any tests that
use DirectSolrSpellChecker).

I think this will make DirectSolrSpellChecker more consistent with the rest of "solrconfig.xml"s
parameter requirements.  The only better option than this, maybe, would to make it flexible
and allow either the Int/Float or String in these cases.  I think this later option is not
necessary however.

> IndexBasedSpellChecker "thresholdTokenFrequency" fails with a ClassCastException on startup
> -------------------------------------------------------------------------------------------
>                 Key: SOLR-2571
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: spellchecker
>    Affects Versions: 1.4.1, 3.1, 4.0
>            Reporter: James Dyer
>            Priority: Minor
>              Labels: whereIsHossManWhenYouNeedHim
>             Fix For: 3.3, 4.0
>         Attachments: SOLR-2571.patch, SOLR-2571.patch, SOLR-2571.patch, SOLR-2571.solr3.2.patch
> When parsing the configuration for thresholdTokenFrequency", the IndexBasedSpellChecker
tries to pull a Float from the DataConfig.xml-derrived NamedList.  However, this comes through
as a String.  Therefore, a ClassCastException is always thrown whenever this parameter is
specified.  The code ought to be doing "Float.parseFloat(...)" on the value.
> This looks like a nice feature to use in cases the data contains misspelled or rare words
leading to spurious "correct" queries.  I would have liked to have used this with a project
we just completed however this bug prevented that.  This issue came up recently in the User's
mailing list so I am raising an issue now.

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message