[ 
https://issues.apache.org/jira/browse/SOLR-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Areek Zillur updated SOLR-5294:
-------------------------------

    Description: 
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}
 

  was:
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.

{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}
 


> 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]

Reply via email to