: But how does the built-in STRING sort work with null values then? And how do : I make a SortComparitor that works?
Built in string sorting uses FieldCache.DEFAULT.getStringIndex() ... any doc without a value ends up without an assignment in StringIndex.order[], so it gets the default value of 0. In most cases only the order[] needs to be consulted and the ints are compared -- in the case of a RemoteSearcher or something like it, the StringIndex.lookup[] can be consulted using the index from StringIndex.order[] -- and the 0th slot of StringIndex.lookup[] is null. (see FieldSortedHitQueue.comparatorString to see what i mean) But that doesn't really relate to what you're doing, because it doesn't even deal with the SortComparator class -- it returns an anonymous direct subclass of ScoreDocComparator. I suspect the ScoreDocComparator in SortComparator is buggy in that it assumes there will be a cachedValue for every ScoreDoc -- even though there is no garuntee of that. if you could submit a test case that reproduces this using a trivial subclass (just return the orriginal String as the Comparable) that can help us verify the bug and the fix. Assuming i'm right, I don'treally have any good work arround suggestion for you beyond overriding newComparator() in your SortComparator subclass to explicitly test for null yourself. : > what's the full stack trace look like? : : See below. thanks ... i just wanted to double check there wasn't some a-typical code path involved (RemoteMultiSearcher or anything) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
