[
https://issues.apache.org/jira/browse/SOLR-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790105#comment-13790105
]
Areek Zillur commented on SOLR-5294:
------------------------------------
Thanks for reviewing this, Robert!
{quote}
Should we think about fixing the spellchecker stuff too (which seems to have
totally separate implementations like FileBased and so on to just change the
dictionary
{quote}
This is an interesting point! After looking through the
AbstractLuceneSpellChecker and all its implementations, it seems like it would
be better to refactor those out too. I feel like that should be considered for
the dictionaryImpl setting to work as expected.
{quote}
I am not sure if we want to keep spell and suggest entangled?
{quote}
It does make sense to untangle them, but I think that by itself is a bigger
issue (I will open up an issue about that and will be happy to work on that)
{quote}
Should we name the DictionaryFactoryBase something better (SuggestDictionary?
SpellingDictionary?)
{quote}
Given the situation, it seems like the dictionary plugin will be shared among
both suggest and spelling; maybe call it DictionaryFactory?
{quote}
Maybe we can simplify the base plugin class to suit more use cases, like remove
the setCore() and just check if it implements CoreAware interface?
{quote}
That sounds good to me.
{quote}
I think it would be ideal if we could eliminate the additional hierarchy of
FileBased* and IndexBased*: couldnt the FileBased impl just take its filename
in via a parameter in params, and IndexBased take its fieldname in params the
same way, and we push up create(IndexSearcher) to the base plugin class (the
file-based just wouldnt use the indexsearcher argument).
{quote}
The reason for having the hierarchy was to separate out the two major types of
dictionaries (index and file-based). I can change that but at the cost of
reduced enforcement.
I will upload another patch, incorporating your feedback!
> Pluggable Dictionary Implementation for Suggester
> -------------------------------------------------
>
> Key: SOLR-5294
> URL: https://issues.apache.org/jira/browse/SOLR-5294
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
> Reporter: Areek Zillur
> Attachments: SOLR-5294.patch, SOLR-5294.patch
>
>
> It would be nice to have the option of plugging in Dictionary implementations
> for the suggester to consume, like that of the lookup implementation that
> allows users to specify which lucene suggesters to use.
> This would allow easy addition of new dictionary implementations that the
> lucene suggesters can consume. New implementations of dictionary like
> (https://issues.apache.org/jira/browse/LUCENE-5251) could be easily added. I
> believe this would give the users more control on what they what their lucene
> suggesters to consume.
> For the implementation, the user can add a new setting in the spellcomponent
> in the solrconfig. The new setting would be a string identifying the class
> path of the dictionary implementation to be used (very similar to the
> existing lookupImpl). This setting would be used to call the relevant
> DictionaryFactory.
> A sample solrconfig file would look as follows (note the new "dictionaryImpl"
> setting):
> {code}
> <searchComponent class="solr.SpellCheckComponent"
> name="fuzzy_suggest_analyzing_with_lucene_dict">
> <lst name="spellchecker">
> <str name="name">fuzzy_suggest_analyzing_with_lucene_dict</str>
> <str name="classname">org.apache.solr.spelling.suggest.Suggester</str>
> <str
> name="lookupImpl">org.apache.solr.spelling.suggest.fst.FuzzyLookupFactory</str>
> <str
> name="dictionaryImpl">org.apache.solr.spelling.suggest.LuceneDictionaryFactory</str>
> <!-- new setting -->
> <str name="storeDir">fuzzy_suggest_analyzing</str>
> <str name="buildOnCommit">false</str>
> <!-- Suggester properties -->
> <bool name="exactMatchFirst">true</bool>
> <str name="suggestAnalyzerFieldType">text</str>
> <bool name="preserveSep">false</bool>
> <str name="field">stext</str>
> </lst>
> {code}
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
