[
https://issues.apache.org/jira/browse/LUCENE-8264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16450134#comment-16450134
]
Erick Erickson commented on LUCENE-8264:
----------------------------------------
bq. I am a true -1 to making a tool that will screw up scoring, sorry.
It was surprising to me how many applications I became involved in where
scoring was irrelevant. I still have to check my assumptions at the door when
working with a new client on that score (little pun there).
Conversely, scoring is everything to other clients I work with and screwing up
scoring would be a major problem for them.
One-size-fits-all doesn't reflect my experience at all though.
Having something that silently "did the best it could" automagically would lead
to it's own problems, so having something like this silently kick in isn't a
good option.
I'm not going to enjoy the conversations that start with "Well, you have to
re-index from scratch for your app or stay on version 7x forever, there is no
other option".
Yet explaining weird results to a customer isn't very much fun either,
especially when it's a surprise to them. At least when they upgrade and things
don't load at all they won't be surprised by subtle problems. Surprised by
total inability to do anything, maybe. But that's not subtle.
I also dread taking customer X and trying to explain to them all the gotcha's
with a tool that upgrades manually. "Well, you'll be able to search but if you
originally indexed with X, then the consequence will be Y" through about 30
iterations.
So I'm a little lost here on what to do. _Strongly_ recommend that people
reindex is obvious, but then maybe the fallback is to send Uwe a lot of
business.......
So is this going to be the official stance going forward? Lucene supports
version N-1 if (and only if) it was originally created with N-1? Or will this
upgrade problem go away absent the original problem and people will be able to
go from an index produced with 8->9->10? Or is that TBD?
> 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
