Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.4.64.0908101054380.28363@radix.cryptio.net>
References: <Pine.LNX.4.64.0908061650200.5844@radix.cryptio.net>
	 <9ac0c6aa0908070947i696be6f7p168b357a3a70866e@mail.gmail.com>
	 <Pine.LNX.4.64.0908101054380.28363@radix.cryptio.net>
Date: Mon, 10 Aug 2009 14:38:39 -0400
Message-ID: <9ac0c6aa0908101138r5efa847es9717dcd622e35193@mail.gmail.com>
Subject: Re: Sorting cleanup and FieldCacheImpl.Entry confusion
From: Michael McCandless <lucene@mikemccandless.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 10, 2009 at 1:57 PM, Chris
Hostetter<hossman_lucene@fucit.org> wrote:
> : I don't know why Entry has "int type" and "String locale", either. =A0I
> : agree it'd be cleaner for FieldSortedHitQueue to store these on its
> : own, privately.
> :
> : Note that FieldSortedHitQueue is deprecated in favor of
> : FieldValueHitQueue, and that FieldValueHitQueue doesn't cache
> : comparators anymore.
>
> yeah ... but i'm hesitent to try and refactor that code at this point,
> especitally if FieldSortedHitQueue is going to be removed in 3.0.
>
> I'm thinking that for the time being, it's probably simpler to just
> comment those properties as being removable once FieldSortedHitQueue is
> removed, and leave them out of the CacheEntry (debugging/sanity) API,
> since there's no code path that will cause them to be set in
> FieldCacheImpl.
>
> is that cool with people?

Sounds good to me!

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org