On Wed, Aug 7, 2013 at 1:18 PM, Anna Björk Nikulásdóttir
<anna.b....@gmx.de> wrote:
> Ah I see. I will look into the AnalyzingInfixSuggester. I suppose it could be 
> useful as an alternative rather to AnalyzingSuggester instead of 
> FuzzySuggestor ?

Yes, but it's very different (it does no fuzzing, and it matches
"infix", ie prefixes of any token in the suggestion).
http://blog.mikemccandless.com/2013/06/a-new-lucene-suggester-based-on-infix.html
describes it.

> What would help in my case as I use the same FST for both analyzers, if the 
> same FST object could be shared among both analyzers. So what I am doing is 
> to use AnalyzingSuggester.store() and use the stored file for 
> AnalyzingSuggester.load() and FuzzySuggester.load().

That's interesting ... so you mean you sometimes want fuzzy
suggestions and sometimes non-fuzzy ones, off the same built
suggester?  I believe AnalyzingSuggester and FuzzySuggester in fact
use the same FST (not certain) ... are you able to do
FuzzySuggester.load from a previous AnalyzingSuggester.store and it
works?  And that's still too much RAM?

> Unfortunately there is no immutable FST class, but as I do not use it in 
> mulithreaded environment, that is probably not a problem, no ? A quick fix 
> could be to copy the analyzer classes and change these to such behaviour and 
> reuse the FST object. Does this make sense functional wise or do I have to 
> expect problems ?

Sharing an FST across analyzing and fuzzy suggesters does seem
worthwhile; it may "just work" today...

> Would a patch for such behaviour make sense for the existing analyzer classes 
> or is this use case too specific ?

It might ... open an issue and we can discuss/iterate there?

Mike McCandless

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

Reply via email to