I think the tool would require you to specify which [numeric] fields need conversion?
And maybe also for collated fields? Mike On Mon, May 3, 2010 at 1:19 PM, Uwe Schindler <[email protected]> wrote: > We will provide it for 4.0 for the index order change and possibly to convert > NumericFields to full-width byte[] (only problem: how to detect them without > strange heuristics?)! > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: [email protected] > > >> -----Original Message----- >> From: Shai Erera [mailto:[email protected]] >> Sent: Monday, May 03, 2010 6:09 PM >> To: [email protected] >> Subject: Re: BytesRef comparable >> >> 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] > > > > --------------------------------------------------------------------- > 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]
