[
https://issues.apache.org/jira/browse/SOLR-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140668#comment-15140668
]
Christine Poerschke commented on SOLR-8621:
-------------------------------------------
[~shaie] - thanks for patch changes to solrconfig.xmls under solr/contrib and
solr/example. Question: if/where the commented out sections correspond
completely to what is 'default merge policy factory' might it make sense to
just completely remove the commented out {{<mergePolicy*>}} element and just
have a comment saying that the default will be used because the
{{<mergePolicyFactory>}} element is absent but something else could be
configured via
{code}
<mergePolicyFacory class="...">
</mergePolicyFacory>
{code}
if required? That would be my preference I think. Alternatively, if we are
keeping and just updating the commented out elements then the {{<mergeFactor>}}
element maps to TieredMergePolicyFactory.maxMergeAtOnce and
TieredMergePolicyFactory.segmentsPerTier but TieredMergePolicy\[Factory\]
itself has no mergeFactor setter. With solrconfig-tieredmergepolicyfactory.xml
I got this wrong also at the first attempt and thus made
[360376095446db236c1708af18b95dd13c605634|http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/36037609]
solr/CHANGES.txt 'Upgrading from 5.4' section change. 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
> Priority: Blocker
> Fix For: 5.5, master
>
> Attachments: SOLR-8621-example_contrib_configs.patch,
> SOLR-8621.patch, explicit-merge-auto-set.patch
>
>
> *<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 summary:+
> * main code changes have been committed to master and branch_5x
> * {color:red}further small code change required:{color} MergePolicyFactory
> constructor or MergePolicyFactory.getMergePolicy method to take IndexSchema
> argument (e.g. for use by SortingMergePolicyFactory being added under related
> SOLR-5730)
> * Solr Reference Guide changes (directly in Confluence?)
> * changes to remaining solrconfig.xml
> ** solr/core/src/test-files/solr/collection1/conf - Christine
> ** solr/contrib
> ** solr/example
> +open question:+
> * Do we want to error if luceneMatchVersion >= 5.5 and deprecated
> mergePolicy/mergeFactor/maxMergeDocs are used? See [~hossman]'s comment on
> Feb 1st. The code as-is permits mergePolicy irrespective of
> luceneMatchVersion, I think.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
