[
https://issues.apache.org/jira/browse/SOLR-9648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15598472#comment-15598472
]
Christine Poerschke commented on SOLR-9648:
-------------------------------------------
I like the idea of using segment merging and a merge policy to upgrade segments.
Wrapping the solrconfig.xml configured merge policy in a {{SolrMergePolicy}}
and thus changing the 'what you configure is what you get' approach, hmm, not
so sure about that though because
* currently force-merge happens only when externally triggered
* the force-merge behaviour added by the wrap is (proposed to be) executed only
on startup
* the configured merge policy could (at least theoretically) disallow force
merges
POC WIP patch notes:
* The {{MAX_UPGRADES_AT_A_TIME = 5;}} sounds similar to what the
[MergeScheduler|http://lucene.apache.org/core/6_2_1/core/org/apache/lucene/index/MergeScheduler.html]
does (unless merge-on-startup bypasses the merge scheduler somehow?)
* IndexWriter has a {{UNBOUNDED_MAX_MERGE_SEGMENTS==-1}} which if made
non-private could perhaps be used in the {{cmd.maxOptimizeSegments =
Integer.MAX_VALUE;}}
* The SolrMergePolicy has no solr dependencies, might it be renamed to
something else and be part of the lucene code base?
[UpgradeIndexMergePolicy|http://lucene.apache.org/core/6_2_1/core/org/apache/lucene/index/UpgradeIndexMergePolicy.html]
also sounds very similar actually.
> Wrap all solr merge policies with SolrMergePolicy
> -------------------------------------------------
>
> Key: SOLR-9648
> URL: https://issues.apache.org/jira/browse/SOLR-9648
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Keith Laban
> Attachments: SOLR-9648-WIP.patch
>
>
> Wrap the entry point for all merge policies with a single entry point merge
> policy for more fine grained control over merging with minimal configuration.
> The main benefit will be to allow upgrading of segments on startup when
> lucene version changes. Ideally we can use the same approach for adding and
> removing of doc values when the schema changes and hopefully other index type
> changes such as Trie -> Point types, or even analyzer changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]