[
https://issues.apache.org/jira/browse/SOLR-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15677547#comment-15677547
]
Shawn Heisey commented on SOLR-9778:
------------------------------------
Devil's advocate comment ... although I suppose this isn't a whole lot
different than many upgrade scenarios:
Say this is added to 6.4. What happens in the luceneMatchVersion.txt file if I
create an index with 6.4 (with luceneMatchVersion NOT in the config), upgrade
to 6.6, configure luceneMatchVersion to 6.6 in solrconfig.xml, and then double
the index size by indexing new documents? I do know that the index will
consist of some segments where the terms are the result of the 6.4 analyzer
settings, some segments that may have different terms (from similar input)
because of the 6.6 settings, and there's a good chance that some segments will
have both -- where a 6.4 segment and a 6.6 segment were merged. This situation
cannot be described by a single txt file.
Just like other upgrade scenarios where luceneMatchVersion is involved, if a
significant bug is addressed by the analyzer changes from 6.4 to 6.6, my
queries may not work right until I fully reindex.
> Make luceneMatchVersion handling easy/automatic
> -----------------------------------------------
>
> Key: SOLR-9778
> URL: https://issues.apache.org/jira/browse/SOLR-9778
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
>
> I was thinking about luceneMatchVersion and how it's annoying to both explain
> and get right, and maintain. I think there's a way in Solr we can do this
> way better:
> When an index is initialized, record the luceneMatchVersion in effect into a
> file in the data directory, like luceneMatchVersion.txt. It's a file that
> will never be modified.
> The luceneMatchVersion in effect is the first of these that are specified:
> * {{<luceneMatchVersion>}} in solrconfig.xml
> * data/luceneMatchVersion.txt
> * {{org.apache.lucene.util.Version.LATEST}}
> With this approach, we can eliminate putting {{<luceneMatchVersion>}} into
> solrconfig.xml by default. Most users will have no need to bother setting
> it, even during an upgrade of either an existing index, or when they
> re-index. Of course there are cases where the user knows what they are doing
> and insists on a different luceneMatchVersion, and they can specify that
> still.
> Perhaps instead of a new file (data/luceneMatchVersion.txt), it might go into
> core.properties. I dunno.
> _(disclaimer: as I write this, I have no plans to work on this at the moment)_
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
