[
https://issues.apache.org/jira/browse/SOLR-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043431#comment-13043431
]
Robert Muir commented on SOLR-2571:
-----------------------------------
Thanks for updating the patch!
{quote}
I found that DirectSolrSpellChecker returns results in a slightly different
format than IndexBasedSpellChecker. Is this OK? Can SOLRJ handle this or do we
need to tweak there?
{quote}
Not sure, I have used DirectSolrSpellChecker with solrj and I didn't have any
problems... but that's not saying there isn't one.
{quote}
Also, in one case IndexBasedSpellChecker returns "correctlySpelled=false" while
DirectSolrSpellChecker returns "correctlySpelled=true". Is this discrepancy
valid?
{quote}
I don't know, what makes this 'decision' of correctlySpelled? Do you know?
Remember also the DirectSolrSpellChecker is a different spellchecker totally
than IndexBasedSpellChecker (it uses a fundamentally different algorithm),
although I tried to keep some of the parameters consistent.
Another question is, there are lots of other float/int arguments to
DirectSolrSpellChecker, maybe we should cut all of these over to <int> and
<float> while we are here?
> IndexBasedSpellChecker "thresholdTokenFrequency" fails with a
> ClassCastException on startup
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-2571
> URL: https://issues.apache.org/jira/browse/SOLR-2571
> 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.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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
