lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Sorting cleanup and FieldCacheImpl.Entry confusion
Date Fri, 07 Aug 2009 16:47:04 GMT
I don't know why Entry has "int type" and "String locale", either.  I
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.

Mike

On Thu, Aug 6, 2009 at 8:07 PM, Chris Hostetter<hossman_lucene@fucit.org> wrote:
>
> Hey everybody, over in LUCENE-1749 i'm trying to make sanity checking of the
> FieldCache possible, and i'm banging my head into a few walls, and hoping
> people can help me fill in the gaps about how sorting w/FieldCache is
> *suppose* to work.
>
> For starters: i was getting confused why some debugging code wasn't showing
> the Locale specified when getting the String[] cache for Locale.US.
>
> Looking at FieldSortedHitQueue.comparatorStringLocale, i see that it calls
> FieldCache.DEFAULT.getStrings(reader, field) and doesn't pass the Locale at
> all -- which makes me wonder why FieldCacheImpl.Entry bothers having a
> locale member at all? ... it seems like the only purpose is so
> FieldSortedHitQueue can abuse the Entry object as a key for it's own "static
> final FieldCacheImpl.Cache Comparators" ... but couldn't it just use it's on
> key object and keep FieldCacheImpl.Entry simpler?
>
> Ditto for the "int type" property of FieldCacheImpl.Entry, which has the
> comment "// which SortField type" ... it's used by FieldSortedHitQueue in
> it's Comparators cache (and getCachedComparator) but FieldCacheImpl never
> uses it, but the time the FieldCache is access, the "type" has already been
> translated into the appropriate method (getInts, getBytes, etc...)
>
>
> if FieldSortedHitQueue used it's own private inner class for it's comparator
> cache, the FieldCacheImpl.Entry code could eliminate a lot of cruft, and the
> class would get much simpler.
>
> Does anyone know a good reason *why* it's implemented the way it currently
> is? or is this simply the end result of code gradually being refactored out
> of FieldCcaheImpl and into FieldSortedHitQueue ?
>
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

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


Mime
View raw message