On Wed, Aug 29, 2012 at 3:13 AM, Uwe Schindler <[email protected]> wrote: > Hi, > > In the early days (I mean in the time when it was already read only until we > refactored the IndexReader.delete()/Codec stuff), this was working, because > the LiveDocs were always handled in a special way. Making it now 100% > read-only is in my opinion very bad, as it does not allow to update documents > in a 3.x index anymore, so you have no chance, you must run IndexUpgrader. >
It didn't really go down like that, instead, at one point, this was working. Then later as the APIs changed, it was not really feasible anymore. I added the UOE for that reason. I knew exactly what the tradeoffs were when I did this. It just happens that now, its (seemingly) easy and feasible to re-enable have it working again (due to changes in LUCENE-4050/LUCENE-4055), which is why I suggested the patch. But we should think it through, be careful, and make sure I'm not missing or forgetting anything: my test is very trivial. I don't think we should add this back compat requirement/test to TestBackwardsCompatibility in trunk. if it goes in, its 4.0 only and only because we are agreeing to do this on a case-by-case basis. In general you cannot 'seamlessly' upgrade from one version to the next. if you have a 3.x index for example, it might contain some 2.x segments and be working fine in 3.x, that doesn't mean 4.x will read it, etc, etc. This is nothing new. So you always must take some measures. At one point we had decided an upgrade-tool-approach to 4.x was fine. I don't think we should forget that either. We just have online back compat because Mike spent a ton of time to do the work. I don't want us to require this "feature" in the future. We might want to refactor codec apis or something like that in 5.0 in a way where its no longer feasible again. -- lucidworks.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
