:-) You're right! It remains the case that INT and FLOAT equivalents of MissingStringLastComparatorSource would be useful for the reverse reverse (i.e. not reverse) case :-)
-----Original Message----- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: 15 July 2006 00:24 To: java-user@lucene.apache.org Subject: RE: MissingStringLastComparatorSource and MultiSearcher : I was wanting to apply this to a field, which sorts on INT. Specifically I'm : trying to achieve reverse chronological sorting on a timestamp field, which : stores YYMMDDHHI (i.e. resolves to 10 minutes and doesn't handle centuries). : Missing timestamps are assumed to be "old" (i.e. should appear at the end). for the record, MissingStringLastComparatorSource isn't really needed in this case. If a missing timestamp field should be interpreted as "old" then normal Lucene "reverse" sorting (either String or int) should work fine for a reverse chronological sort -- because in normal String sorting "null" is low, and (i'm 99% sure) in int sorting "null" is assigned a value of 0. In both cases, your "old" docs will wind up where you want them. MissingStringLastComparatorSource comes in handy when you want docs without a timestamp value to appear at the end of your list *regardless* of wether the user selected "oldest first" or "newest first" -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
