lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-2370) Let some UpdateProcessors be default without explicitly configuring them
Date Thu, 17 Feb 2011 02:21:24 GMT

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


Mime
View raw message