Lets make SolrSpellChecker keep the standard init method structure akin to NamedListInitializedPlugin. Let the build method return the dictionary name. In the current patch, even if build fails, the spell checker would get added to the map.
The approach is to then use the build in the prepare method, much like the cmd=rebuild. Thus, spelling index creation is much like in the RequestHandler mode and gets around the firstSearcher issue. I am working on the integration into the Component at the moment, which is why you only see it in the tests.
So, I am not sure if this makes sense. Right now, I have it so that we extract the necessary pieces in the init, but then they are applied during build. I guess the question is what should happen if "build" fails? Should we just remove that speller and log a warning? Or should it throw an exception? I am leaning towards the former.
Rename AbstractLuceneSpellerSpellChecker to something shorter.
OK, I will try to think of something.
Lets remove the SolrSpellChecker#getSuggestion(String query, IndexReader reader, boolean onlyMorePopular) method completely. The other getSuggestion method will be called with count=1 if count is absent in the query.
I was just thinking the same thing. Done.
The configuration looks scary. There's no value added by the repeated spellchecker nodes. I propose the following syntax:
All Solr config's look scary to me! However...
I can imagine an implementation that looks like:
I agree, however, we can flatten mine one level, but keep the name spellchecker instead of dictionary.
Here's an iteration:
<searchComponent name="spellcheck" class="org.apache.solr.handler.component.SpellCheckComponent">
<!-- omp = Only More Popular -->
<!-- exr = Extended Results -->
<!-- The number of suggestions to return -->
Last but not the least, Grant, do you know of a freely available spell checker implementation that someone may want to plugin instead of the Lucene SpellChecker? In other words, is this a real use-case or something we're imagining up? If we don't know of something that can be used right now, maybe we're better off postponing this change until users really need it and ask for it. I don't like the complexity this feature is asking for.
Yes, I have an immediate need for it. The Lucene SpellChecker isn't all that good, IMO, and I want to offer something different without having to fork and have my own SpellChecker Component when the output is the same.