On Wed, Jun 10, 2009 at 5:07 PM, Uwe Schindler<u...@thetaphi.de> wrote: > I would really like to leave this optimization out for 2.9. We can still add > this after 2.9 as an optimization. The number of bits encoded into the > TermPosition (this is really a cool idea, thanks Yonik, I was missing > exactly that, because you do not need to convert the bits, you can directly > put them into the index as int and use them on the query side!) is simply 0 > for indexes created with 2.9. With later versions, you could also shift the > lower bits into the TermPosition and tell TrieRange to filter them.
I agree, let's aim for after 3.0 for this. (Note that, in theory, 3.0 should follow quickly after 2.9, having "only" removed deprecated APIs, changed settings, etc.). Can you open & issue & mark as 3.1? > 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). +1 > 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"). > Now the oen question: Which name for the numeric range queries/fields? :-( How about: Range* -> TermRange* TrieRange* -> NumericRange* FieldCacheRangeFilter -> FieldCacheTermRangeFilter ConstantScoreRangeQuery stays as is (it's deprecated) Are there any others that need renaming? Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
