[ 
https://issues.apache.org/jira/browse/SOLR-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140676#comment-15140676
 ] 

Christine Poerschke commented on SOLR-8621:
-------------------------------------------

bq. ... what does SortingMergePolicyFactory need from IndexSchema that it 
cannot create on its own? It already receives the sort-by fields and order in 
the config, all it needs to do is to create a Sort class. What does it get from 
IndexSchema then?

The plan so far was that the sort would be specified as a string e.g.
{code}
<str name="sort">popularity desc, timestamp desc</str>
{code} in the same way as when a {{&sort=...}} parameter is passed as part of a 
select request. The solrconfig.xml SortingMergePolicyFactory's sort string is 
then parsed using the essentially the same methods used for parsing the sort 
parameter in the select request e.g. [SortSpecParsing.parseSortSpec(sortArg, 
schema)|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/SortSpecParsing.java#L84]
 - does that kind of make sense?

bq. ... It already receives the sort-by fields and order in the config, all it 
needs to do is to create a Sort class ...

Are you saying that perhaps there is a way to create the Sort class without use 
of {{IndexSchema}} if the solrconfig.xml sort-by fields and order are provided 
in a structured way that requires no parsing? Interesting idea, let me look 
into that a little further.

> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to