lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2675) Add support for 3.0 indexes in 2.9 branch
Date Fri, 29 Oct 2010 10:12:19 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926226#action_12926226
] 

Michael McCandless commented on LUCENE-2675:
--------------------------------------------

So, first off, Lucene's bw compat policy has never ensured this
"reverse compat".  Promising this would have been exceptionally
costly, in the past.  Once a new major release "kisses" your index, it
cannot be used by older versions of Lucene.

However, now with the switch to pluggable codecs in 4.0, it would be
conceptually possible to make a codec that ensures no change to the
index format, even on upgrade of the software.  And I think such a
codec would be reasonable to offer (we already basically have the
"hard part" done, with the preflex write codec, but it's only exposed
for testing).  But... nobody has stepped up to create this for
4.0... and it's not clear anybody will of course.

That this is so trivial really is a reflection of our crazy major
release criteria in the past (ie nothing of consequence changes going
from X.9 -> (X+1).0!).  Of course this is now changed, ie, 4.0 is
changing tons from 3.x.

I do appreciate the motivation for this, ie to allow an app to "try"
updating the software (Lucene 2.x -> 3.x) fully independently of
updating the index format.  It's a valid use case.

Net/net I'm fine with this change.  But we should advertise very
clearly that this is not in general promised by Lucene.  It'll be on a
case by case basis.  EG even if someone steps up and we make a codec
for 4.0 that can read/write the 3.x index format, that's still not
ensured going forward (unless we make a change to our back-compat
policy, which is a separate discussion).


> Add support for 3.0 indexes in 2.9 branch
> -----------------------------------------
>
>                 Key: LUCENE-2675
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2675
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 2.9, 2.9.1, 2.9.2, 2.9.3
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>            Priority: Minor
>             Fix For: 2.9.4
>
>         Attachments: index.30.cfs.zip, index.30.nocfs.zip, LUCENE-2675.patch
>
>
> There was a lot of user requests to be able to read Lucene 3.0 indexes also with 2.9.
This would make the migration easier. There is no problem in doing that, as the new stored
fields version in Lucene 3.0 is only used to mark a segment's stored fields file as no longer
containing compressed fields. But index format did not really change. This patch simply allows
FieldsReader to pass a Lucene 3.0 version number, but still writes segments in 2.9 format
(as you could suddenly turn on compression for added documents).
> I added ZIP files for 3.0 indexes for TestBackwards. Without the patch it does not pass,
as FieldsReader complains about incorrect version number (although it could read the file
easily). If we would release maybe a 2.9.4 release of Lucene we should include that patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message