lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: BytesRef comparable
Date Mon, 03 May 2010 09:36:05 GMT
It used to implement Comparable (hardwired to natural byte[] order),
but I removed it, so that all comparisons are forced to be explicit.
The problem is... it's dangerous to assume comparison in natural order
is always correct.  Eg Lucene today sorts terms using
UTF8SortedAsUTF16Comparator (which is not natural byte[] ordering).

Of course we are moving away from this, so terms will by default be
sorted in Unicode code point order (which matches UTF8 byte[] natural
order), under LUCENE-2426, but a codec could still customize the sort
order.

We could still put it back, hardwired to natural byte order?  And
javadoc the dangers...

Or I guess we could tell each BytesRef the comparator it should
delegate to, but that's rather inefficient.

Where are you needing to compare BytesRefs?  And which container won't
accept Compator...?

Mike

On Sun, May 2, 2010 at 1:32 PM, Yonik Seeley <yonik@lucidimagination.com> wrote:
> Any objections to making BytesRef comparable?  It would make it much
> easier to use with containers that don't take comparators as
> parameters.
>
> -Yonik
> Apache Lucene Eurocon 2010
> 18-21 May 2010 | Prague
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message