[
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: [email protected]
For additional commands, e-mail: [email protected]
