[
https://issues.apache.org/jira/browse/SOLR-5730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15109442#comment-15109442
]
Hoss Man commented on SOLR-5730:
--------------------------------
Probably a naive question, but...
I understand that the reason we need new config syntax is to be able to wrap
whatever was specified by {{<mergePolicy/>}} -- but i'm not really a fan of the
2 new disjoint top level config options. Why not keep those two concepts
(should we sort the merges? how should we sort the merges?) in a single place?
(my gut says solrconfig.xml since that's where other merge related settings
live.)
ie...
{code}
<sortMerges enabled="true">popularity desc, timestamp desc</sortMerges>
{code}
what's the motivation/conceptual reasoning behind part of that being configured
in the schema and part of it in solrconfig?
> 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-part2of2.patch
>
>
> *Example configuration (SortingMergePolicy):*
> solrconfig.xml
> {noformat}
> <useSortingMergePolicy>true</useSortingMergePolicy>
> {noformat}
> schema.xml
> {noformat}
> <mergeSortSpec>timestamp desc</mergeSortSpec>
> {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
