Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <50E85C764334475D8E8C8597EA2EC5EB@VEGA>
References: <85d3c3b60906091932i591ef6f4gcc950586b15d4506@mail.gmail.com>
	 <9ac0c6aa0906100404y60f77270l31bcbf32c386d479@mail.gmail.com>
	 <85d3c3b60906101058w1f6b5fc5re5a2911cdc8053c1@mail.gmail.com>
	 <444929E412B144B6AB5F6CF3CC919D36@VEGA>
	 <9ac0c6aa0906101145p3450edf6v2a9378c8925412b8@mail.gmail.com>
	 <D2F38D08D3F848768F7DA2B14B8120A0@VEGA>
	 <c68e39170906101219j73d05af3gcb42b99bca356d82@mail.gmail.com>
	 <9ac0c6aa0906101243o1f018b84h929e357e0fa8f88e@mail.gmail.com>
	 <c68e39170906101310m1afba606kf64e865288dff55e@mail.gmail.com>
	 <50E85C764334475D8E8C8597EA2EC5EB@VEGA>
Date: Wed, 10 Jun 2009 17:23:49 -0400
Message-ID: <9ac0c6aa0906101423k71d434bp306077f60e1db5d3@mail.gmail.com>
Subject: Re: Payloads and TrieRangeQuery
From: Michael McCandless <lucene@mikemccandless.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Wed, Jun 10, 2009 at 5:07 PM, Uwe Schindler<uwe@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org