lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasik Pandey <>
Subject Re: Efficient Sorting of Hits/Results Using an Encoded Date Field
Date Thu, 14 Apr 2005 04:40:39 GMT
Hello Tim,

> Yes - the sorting custom comparator was only set up to use
> Comparable.compareTo() - it can't really compare native types using < or >.

I was thinking that another method might better handle this, for
instance the SortField.CUSTOM "type" handling in the "switch"
statements of FieldDocSortedHitQueue.lessThan() method could possibly
look something like

case SortField.CUSTOM:
c = sortFields[i].getFactory().compare(fieldDocA.fields[i],
Implementations of a SortField.getFactory().compare(FieldDoc docA,
FieldDoc docB) method could also handle any necessary decoding of
field values.

> 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).  

Actually "timestamps" are needed in this case, sorry about over simplifying...

> I suppose the classes could be extended to sort by longs

I think I almost have that done. The FieldDocSortedHitQueue.lessThan()
method seems to be the only thing I can't seem to get around.

IIf we can find away around that last issue, I would like you to have
a look at the code once I have tested+documented.


> >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:
> For additional commands, e-mail:

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

View raw message