Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Message-ID: <23667427.430151285623632666.JavaMail.jira@thor>
Date: Mon, 27 Sep 2010 17:40:32 -0400 (EDT)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Subject: [jira] Issue Comment Edited: (LUCENE-2675) Add support for 3.0
 indexes in 2.9 branch
In-Reply-To: <21287339.429611285621896462.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Uwe Schindler edited comment on LUCENE-2675 at 9/27/10 5:39 PM:
----------------------------------------------------------------

Forget about Java versions. Almost everybody who migrates to 3.0 already uses Java 1.5 or 1.6. The problem is during the migration phase (when you undeprecate your code) you cannot switch between both versions easily as soon as you touch an index with 3.0, it will not open anymore in 2.9, but in reality its the same index version, there is *no fileformat change* at all! The version number is simply a marker for SegmentMerger in 3.0 that it can raw-copy documents because they do not contain compression anymore. If we would not have removed compression in 3.0, the file format would have been identical.

As we declare 2.9 and 3.0 as feature-identical even in the latest version, it is not understandable to anyone why they cannot open an 3.0 index with 2.9 and vice versa. For unicode reasons you should then also disallow opening a 2.9 index with 3.0 :-) I got requests (even on java-user, but also from my customers) quite often about that and one user that wants to migrate to 3.0 through 2.9 again asked me today.

I just repeat: The index format is identical!

Maybe we have other comments, I will only commit this if we have an agreement and only if we would release 2.9.4.

      was (Author: thetaphi):
    Forget about Java versions. Almost everybody who migrates to 3.0 already uses Java 1.5 or 1.6. The problem is during the migration phase (when you undeprecate your code) you cannot switch between both versions easily as soon as you touch an index with 3.0, it will not open anymore in 2.9, but in reality its the same index version, there is *no fileformat change* at all! The version number is simply a marker for SegmentMerger in 3.0 that it can raw-copy documents because they do not contain compression anymore. If we would not have removed compression in 3.0, the file format would have been identical.

As we declare 2.9 and 3.0 as feature-identical even in the latest version, it is not understandable to anyone why they cannot open an 3.0 index with 2.9 and vice versa. For unicode reasons you should then also disallow opening a 2.9 index with 3.0 :-) I got requests on java-user quite often about that and one user that wants to migrate to 3.0 through 2.9 again asked me today.

I just repeat: The index format is identical!

Maybe we have other comments, I will only commit this if we have an agreement and only if we would release 2.9.4.
  
> 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