[
https://issues.apache.org/jira/browse/SOLR-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15128081#comment-15128081
]
Shai Erera commented on SOLR-8621:
----------------------------------
Thanks [~cpoerschke]. I've also started to make some changes, so I'll rebase on
yours after you push them. If you haven't done so already, I'll move the
factory under o.a.solr and adjust the relevant classes.
BTW, I think we should split this into multiple commits:
# Introduce {{MergePolicyFactory}} and some implementing classes. Add a
*warning* to {{SolrIndexConfig}}. That way, all existing {{solrconfig.xml}}
will continue to work.
# Change all {{solrconfig.xml}} to use the new {{<mergePolicyFactory>}}, and
change the *warning* to an error in {{SolrIndexConfig}} on trunk and keep the
warning on 5x.
Also, I would personally start with only supporting simple MPF for now, because
the wrapped ones need a bit of discussion I feel (per the review I've done).
E.g. {{UpgradeIndexMergePolicyFactory}} hardcodes the _prefix_ properties to
"base", but it's not documented anywhere. I think that we can generalize the
whole idea of wrapping MPF with something like this (indentations for clarity
only)
{code}
<!-- public MyInstrumentedMergePolicy(MergePolicy mergePolicy) { -->
<mergePolicyFactory class="MyInstrumentedMergePolicyFactory">
<int name="instrumentationLevel">42</int>
<str name="wrapped.key">mergePolicy</str>
<str name="mergePolicy">SortingMergePolicyFactory</str>
<str name="mergePolicy.sort">timestamp desc</str>
<str name="mergePolicy.wrapped.key">in</str>
<str name="mergePolicy.in">TieredMergePolicyFactory</str>
<int name="mergePolicy.in.segmentsPerTier">42</int>
</mergePolicyFactory>
{code}
Also, I feel that having a fixed/expected key name for the class will be useful
in the code too, e.g.:
{code}
<!-- public MyInstrumentedMergePolicy(MergePolicy mergePolicy) { -->
<mergePolicyFactory class="MyInstrumentedMergePolicyFactory">
<int name="instrumentationLevel">42</int>
<str name="wrapped.key">mergePolicy</str>
<str name="mergePolicy.class">SortingMergePolicyFactory</str>
<str name="mergePolicy.sort">timestamp desc</str>
<str name="mergePolicy.wrapped.key">in</str>
<str name="mergePolicy.in.class">TieredMergePolicyFactory</str>
<int name="mergePolicy.in.segmentsPerTier">42</int>
</mergePolicyFactory>
{code}
It's then both consistent with the wrapped {{<mergePolicyFactory>}} element
(taking a 'class') and also in the code we can just do {{args.get("class")}}
and fail early if none is defined. What do you think?
> solrconfig.xml: deprecate/replace <mergePolicy> with <mergePolicyFactory>
> -------------------------------------------------------------------------
>
> Key: SOLR-8621
> URL: https://issues.apache.org/jira/browse/SOLR-8621
> Project: Solr
> Issue Type: Task
> Reporter: Christine Poerschke
> Assignee: Christine Poerschke
>
> *<mergePolicyFactory> end-user benefits:*
> * Lucene's UpgradeIndexMergePolicy can be configured in Solr
> * (with SOLR-5730) Lucene's SortingMergePolicy can be configured in Solr
> * customisability: arbitrary merge policies including wrapping/nested merge
> policies can be created and configured
> *(proposed) roadmap:*
> * solr 5.5 introduces <mergePolicyFactory> support
> * solr 5.5(\?) deprecates (but maintains) <mergePolicy> support
> * solr 6.0(\?) removes <mergePolicy> support
> +work-in-progress git branch:+
> [master-solr-8621|https://github.com/apache/lucene-solr/tree/master-solr-8621]
--
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
