lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Efficient Sorting of Hits/Results Using an Encoded Date Field
Date Thu, 14 Apr 2005 00:05:22 GMT

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?


>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

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

View raw message