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], fieldDocB.fields[i]); break; 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. Regards, Rus > >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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
