[
https://issues.apache.org/jira/browse/SOLR-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995639#comment-12995639
]
Yonik Seeley commented on SOLR-2370:
------------------------------------
I'd like to hear from others, but at first blush it seems like a good idea.
aside: The description field of a JIRA issue is repeated in every update to the
mailing list. It's probably best to use a few sentences to summarize and put
more meat in a comment.
> Let some UpdateProcessors be default without explicitly configuring them
> ------------------------------------------------------------------------
>
> Key: SOLR-2370
> URL: https://issues.apache.org/jira/browse/SOLR-2370
> Project: Solr
> Issue Type: Improvement
> Components: update
> Reporter: Jan Høydahl
> Labels: UpdateProcessor, UpdateProcessorChain
>
> Problem:
> Today the user needs to make sure that crucial UpdateProcessors like the Log-
> and Run UpdateProcessors are present when creating a new
> UpdateRequestProcessorChain. This is error prone, and when introducing a new
> core UpdateProcessor, like in SOLR-2358, all existing users need to insert
> the changes into all their pipelines.
> A customer made pipeline should not need to care about distributed indexing,
> logging or anything else, and should be as slim as possible.
> Proposal:
> The proposal is to lend from the <first-components> and <last-components>
> pattern used in RequestHandler configs. In that way, we could let all core
> processors be included either first or last by default in all UpdateChains.
> To do this, we need a place to configure the defaults, e.g. by a
> default="true" param:
> {code:xml}
> <updateRequestProcessorChain name="default" default="true">
> <first-processors>
> <processor class="solr.DistributedUpdateRequestProcessor"/>
> </first-processors>
> <last-processors>
> <processor class="solr.LogUpdateProcessorFactory" />
> <processor class="solr.RunUpdateProcessorFactory" />
> </last-processors>
> </updateRequestProcessorChain>
> {code}
> Next, the customer made chain will be only the "center" part:
> {code:xml}
> <updateRequestProcessorChain name="mychain">
> <processor class="my.nice.DoSomethingProcessor"/>
> <processor class="my.nice.DoAnotherThingProcessor"/>
> </updateRequestProcessorChain>
> {code}
> To override the core processors config for a particular chain, you would
> start a clean chain by parameter reset="true"
> {code:xml}
> <updateRequestProcessorChain name="mychain" reset="true">
> <processor class="my.nice.DoSomethingProcessor"/>
> <processor class="my.nice.DoAnotherThingProcessor"/>
> <processor class="solr.RunUpdateProcessorFactory" />
> </updateRequestProcessorChain>
> {code}
> If you only need to make sure that one of your custom processors run at the
> very beginning or the very end, you could use:
> {code:xml}
> <updateRequestProcessorChain name="mychain">
> <processor class="my.nice.DoSomethingProcessor"/>
> <processor class="my.nice.DoAnotherThingProcessor"/>
> <last-processors>
> <processor class="solr.MySpecialDebugProcessor" />
> </last-processors>
> </updateRequestProcessorChain>
> {code}
> The default should be reset="false", but the example schema could keep the
> default chain commented out to provide backward compatibility for upgraders.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
