I think we'd need richer communication between MTQ and its subclasses, so that eg your enum would return a Query instead of a Term?
Then you'd either return a TermQuery, or, a BooleanQuery that's filtering the TermQuery? But yes, doing after 3.0 seems good! Mike On Wed, Jun 10, 2009 at 5:26 PM, Uwe Schindler<u...@thetaphi.de> wrote: >> I would like to go forward with moving the classes into the right packages >> and optimize the way, how queries and analyzers are created (only one >> class >> for each). The idea from LUCENE-1673 to use static factories to create >> these >> classes for the different data types seems to be more elegant and simplier >> to maintain than the current way (having a class for each bit size). >> >> So I think I will start with 1673 and try to present something useable, >> soon >> (but without payloads, so the payload/position-bits setting is "0"). > > Another question not so simple to answer: When embedding these TermPositions > into the whole process, how would this work with MultiTermQuery? The current > algorithm is simple: The TrieRangeTermEnum simply enumerates the possible > terms from the index and MTQ creates the BitSet or a BooleanQuery of > TermQueries. How to do this with positions? In both cases there need > specialities (the TermEnum must return that the actual term is a > payload/position one and must filter using TermPositions). For the filter > its then easy, the TermQueries added to BooleanQuery in the other case must > also use the payloads. Questions & more questions. > > I tend to release TrieRange with 2.9 without Positions/Payloads. > > Uwe > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
