[ 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