[
https://issues.apache.org/jira/browse/SOLR-5730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119121#comment-15119121
]
Christine Poerschke commented on SOLR-5730:
-------------------------------------------
I like the idea of a {{MergePolicyFactory}} and the idea of
{{delegate.something}} notation is also interesting.
There would have to be out-of-the-box factories for all existing non-wrapping
merge policies e.g.
{code}
<!-- public TieredMergePolicy() { -->
<mergePolicyFactory class="TieredMergePolicyFactory">
<int name="segmentsPerTier">42</int>
</mergePolicyFactory>
{code}
An out-of-the-box factory would also be provided for existing plain wrapping
merge policies e.g.
{code}
<!-- public UpgradeIndexMergePolicy(MergePolicy base) { -->
<mergePolicyFactory class="UpgradeIndexMergePolicyFactory">
<str name="base">TieredMergePolicyFactory</str>
<int name="base.segmentsPerTier">42</int>
</mergePolicyFactory>
{code}
The factory for building sorting merge policies could look something like this:
{code}
<!-- public SortingMergePolicy(MergePolicy in, Sort sort) { -->
<mergePolicyFactory class="SortingMergePolicyFactory">
<str name="in">TieredMergePolicyFactory</str>
<int name="in.segmentsPerTier">42</int>
<str name="sort">timestamp desc</str>
</mergePolicyFactory>
{code}
For consistency we should (in my opinion) conceptually support wrapping of
wrapping merge policies e.g. someone could go and create their own
MyInstrumentedMergePolicyFactory factory and use it like this:
{code}
<!-- public MyInstrumentedMergePolicy(MergePolicy mergePolicy) { -->
<mergePolicyFactory class="MyInstrumentedMergePolicyFactory">
<str name="mergePolicy">SortingMergePolicyFactory</str>
<str name="mergePolicy.in">TieredMergePolicyFactory</str>
<int name="mergePolicy.in.segmentsPerTier">42</int>
<str name="mergePolicy.sort">timestamp desc</str>
<int name="instrumentationLevel">42</int>
</mergePolicyFactory>
{code}
+ticketing details:+ if we choose to go down the {{MergePolicyFactory}} route
then i would suggest this would be best done via a separate JIRA ticket and
when that separate JIRA ticket completes the SOLR-5730 efforts here would
resume/continue.
> make Lucene's SortingMergePolicy and EarlyTerminatingSortingCollector
> configurable in Solr
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-5730
> URL: https://issues.apache.org/jira/browse/SOLR-5730
> Project: Solr
> Issue Type: New Feature
> Reporter: Christine Poerschke
> Assignee: Christine Poerschke
> Priority: Minor
> Attachments: SOLR-5730-part1of2.patch, SOLR-5730-part1of2.patch,
> SOLR-5730-part2of2.patch, SOLR-5730-part2of2.patch
>
>
> *Example configuration (solrconfig.xml):*
> {noformat}
> <sortMerges enable="true">
> <str name="sort">timestamp desc</str>
> </sortMerges>
> {noformat}
> *Example use (EarlyTerminatingSortingCollector):*
> {noformat}
> &sort=timestamp+desc&segmentTerminateEarly=true
> {noformat}
--
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
