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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
