Rus,
Yes - the sorting custom comparator was only set up to use Comparable.compareTo() - it can't really compare native types using < or >.
I think your best bet might be to encode your dates at index time into integers and put those in the index (assuming you really need Dates and not Timestamps). Then the field will automatically sort as an int. You could also store a user-readable date in a separate field if you wanted.
I suppose the classes could be extended to sort by longs, but for dates you shouldn't need that much precision, right?
Tim
I was wondering if there is a date sort implementation which is more efficient than just sorting dates as encoded Strings or as custom Comparable objects. If there isn't I have quickly built one based upon Tim's SortComparatorSource interface. I would be glad to share it if there is enough interest. Bascially, using an custom implementation of SortComparatorSource (DateSortComparator) for value comparison, String-encoded Date values are decoded to "long" values using the method "stringToTime" from either the DateField or DateTools class and stored into a DecodedLongFieldCacheImpl. The only thing I don't understand is the the association of the SortField.CUSTOM type to any SortComparatorSource passed into the SortField Constructor "public SortField (String field, SortComparatorSource comparator)". It seems like the SortField.CUSTOM "type" handling in the "switch" statements of FieldDocSortedHitQueue.lessThan() method are incongruent with the idea that a low-level custom SortComparatorSource can be created which does native type comparisons rather can using the generic Comparable.compareTo(Object).
Regards, Rus
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
