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
