[
https://issues.apache.org/jira/browse/SOLR-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-2370:
------------------------------
Description:
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.
was:
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.
(Moving proposal to a comment as per best-practice)
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.
> 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.
--
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]
