[
https://issues.apache.org/jira/browse/LUCENE-8264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16447804#comment-16447804
]
Uwe Schindler edited comment on LUCENE-8264 at 4/23/18 9:16 AM:
----------------------------------------------------------------
Ah, I was always using a FilterLeafReader with a SlowCodecReaderWrapper
(because those people needed to add DocValues from UninvertingReader - the one
from solr). So yes, in my case, the FilterLeafReader war returning {{new
LeafMetadata(7, Version.LUCENE_7_0_0, null)}} in {{getMetadata()}}. Very easy
and worked. Broken offsets were not an issue there, if they would have been we
may have removed them by changing the field metadata from the filter reader.
Alternatively, you can first upgrade to 6.x withe the same construction of
filter readers, leaving out metadata (I think I did this, because they were
coming from Lucene 3.6). As all segments are written completely new, you can
then migrate to 7 without hassle.
I just wanted to say: It's good that we still allow to do the migration, but I
agree with you: This should not be provided by default in Solr or Lucene.
People need to know how about the side-effects.
was (Author: thetaphi):
Ah, I was always using a FilterLeafReader with a SlowCodecReaderWrapper
(because those people needed to add DocValues from UninvertingReader - the one
from solr). So yes, in my case, the FilterLeafReader war returning {{new
LeafMetadata(Version.LUCENE_7_0_0, Version.LUCENE_7_0_0, null)}} in
{{getMetadata()}}. Very easy and worked. Broken offsets were not an issue
there, if they would have been we may have removed them by changing the field
metadata from the filter reader.
Alternatively, you can first upgrade to 6.x withe the same construction of
filter readers, leaving out metadata (I think I did this, because they were
coming from Lucene 3.6). As all segments are written completely new, you can
then migrate to 7 without hassle.
I just wanted to say: It's good that we still allow to do the migration, but I
agree with you: This should not be provided by default in Solr or Lucene.
People need to know how about the side-effects.
> Allow an option to rewrite all segments
> ---------------------------------------
>
> Key: LUCENE-8264
> URL: https://issues.apache.org/jira/browse/LUCENE-8264
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
>
> For the background, see SOLR-12259.
> There are several use-cases that would be much easier, especially during
> upgrades, if we could specify that all segments get rewritten.
> One example: Upgrading 5x->6x->7x. When segments are merged, they're
> rewritten into the current format. However, there's no guarantee that a
> particular segment _ever_ gets merged so the 6x-7x upgrade won't necessarily
> be successful.
> How many merge policies support this is an open question. I propose to start
> with TMP and raise other JIRAs as necessary for other merge policies.
> So far the usual response has been "re-index from scratch", but that's
> increasingly difficult as systems get larger.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
