> Dawid, the thing is that I am not even sure that Automata are the perfect > fit for my project and I thought some literature on it would help me decide > whether to use it or not.
Still looks to me like you're approaching the problem from the wrong side or don't want to share the core problem which you're trying to solve. All automata inside Lucene serve a purpose somewhere -- they're not part of Lucene's search API or even the core goal of the library; they merely serve as an implementation detail for some higher-level use cases (say, efficient storage of a large number of term-value pairs). It is this kind of "high-level goal" I asked about. Your answer only adds to the mystery: > Furthermore, I'll probably have to modify Lucene's > Automata implementation for my project, and I thought that reading about > design choices would allow me to better understand how to improve it. Why? Is there something in Lucene's core search API that is not working for you? Or maybe you need an automaton library, not Lucene? In that case there are a few other, more efficient alternatives out there (in C/C++). > 1. I need to be able to add data to an FST (add new strings and update the > mapped value in the case of FST). I thought about a multi-layer strategy > where old data has been compressed to an FST format whereas new data is > added to a delta partition (probably a BST or a simple list). Sure, it'll work. You could also build a dynamically merged view of several FSTs (if their keys are distinct, or provide a value-merging function). It'd be a nice addition to Lucene if you can share it. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
