lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: lucene 2.9 sorting algorithm
Date Tue, 20 Oct 2009 13:31:10 GMT
> Actually though - how are we supposed to get back there? I don't think
> its as simple as just not removing the deprecated API's. Doesn't even
> seem close to that simple. Its another nightmare. It would have to be
> some serious wins to go through that pain starting at a 3.0 release
> wouldn't it? We just had a ton of people switch. We would have to
> deprecate a bunch of stuff. Hard to imagine wanting to switch now - the
> new API is certainly not that bad.

It is not bad, only harder to understand (for some people). As noted in my
previous mail, we could start the same discussion like with the Collectors:

Should we provide some easy to use FieldComparators, that can be used as a
starting point? Maybe someone that looks like the comparators used for
byte/int/short and so on, but has an abstract method
getComparable(IndexReader reader, int doc) [relative to current reader] that
returns an Comparable<T>. All other methods and Arrays use the datatype
Comparable<T> and implement just the compare functions inner slot and
botton. Or maybe another wrapper that takes an java.lang.Comparator<T> and a
method T getSortValue(IndexReader reader, int doc) and implements the
comparison. We had something like this in the old API, too. It could be
implemented by a wrapper with this easy API.

These wrapper classes may be lot of slower than native FieldComparators
directly working on the native types, but would help to create simple
sorting for things like geo-distances, where the calculation of the field
values/Comparable<T> takes most time.

So some easy-access or sample comparators like this in contrib would be


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

View raw message