Trunk matters here only if this changes within the same manor release. If sort order changes between 4.0 and 5.0, we'll needto provide and index migration tool or something, because such change does not justify reindexing.
Shai On Monday, May 3, 2010, Michael McCandless <[email protected]> wrote: > On Mon, May 3, 2010 at 10:37 AM, Yonik Seeley > <[email protected]> wrote: >> On Mon, May 3, 2010 at 6:30 AM, Michael McCandless >> <[email protected]> wrote: >>> But... we probably should do this after we switch to sorting terms by >>> unicode code point order? (LUCENE-2426) >> >> So perhaps we should define this in terms of Lucene's default index >> order instead... so it could be UTF16 order for now, and switch to >> code-point / unsigned byte order when the index format does? > > This seems a bit dangerous (first sorts by UTF16 order and then by > codepoint order, when we switch)... ie, I'd rather make BytesRef > compare by code point order, after we've cutover to that order by > default. > > Though it is "trunk", so, we could do that I guess... (Erik: this is > what "unstable" means ;) ). > > Mike > > --------------------------------------------------------------------- > 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]
