lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Sorting cleanup and FieldCacheImpl.Entry confusion
Date Fri, 07 Aug 2009 00:07:16 GMT

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 

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 ?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message