On Mon, Nov 29, 2010 at 20:51, DM Smith <dmsmith...@gmail.com> wrote: > The other thing I'd like is for the spec to be save along side of the index > as a manifest. From earlier threads, I can see that there might need to be > one for writing and another for reading. I'm not interested in using it to > construct an analyzer, but to determine whether the index is invalid wrt to > the analyzer currently in use. You can already implement such behaviour with 3.x branch of Lucene. It has IW.commit(Map<String, String> userdata) method, that allows you to commit with arbitrary payload, that binds to segment and can be read back later.
> I think there is a problem with deprecating and removing constants too. > In trunk, which will be 4.0, it needs to be able to read and/or upgrade 2.x > indexes. From an analyzer perspective, an index is invalid if the analyzer > would produce a different token stream for the same input. If the 2.x > version constants are gone, then the index built with 2.x version > constants is no longer valid. (It might be valid, but how can one have any > confidence of that?) Upgrading the index to the new internal format > cannot change this. A buggy lowercase Turkish word will still be buggy > after upgrade. (This is a 3.0 version constant that in 5.0 will still need to > be around). I think it was declared that Lucene does not provide index compatibility across more than a single major revision. Thus, we don't guarantee reading 2.x index with 4.0 Lucene. So, we can drop 2.x constants and compatibility. But we still have to support 3.x. In version 5.0 then we're dropping 3.x constants and support for bugs/deprecated features of 3.x. -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Phone: +7 (495) 683-567-4 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
