[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616457#action_12616457
]
Shalin Shekhar Mangar commented on SOLR-269:
--------------------------------------------
I've read through most of the discussion here and the wiki page at
http://wiki.apache.org/solr/UpdateRequestProcessor but I couldn't understand
the reasons behind the current design.
Looking at the configuration we have:
{code:xml}
<updateRequestProcessor>
<factory name="standard" class="solr.ChainedUpdateProcessorFactory"
default="true" >
<chain class="org.apache.solr.ConditionalCopyProcessorFactory" />
<chain class="solr.RunUpdateProcessorFactory" />
<chain class="solr.LogUpdateProcessorFactory" />
</factory>
</updateRequestProcessor>
{code}
Why can't it be written as:
{code:xml}
<updateRequestProcessor name="standard" default="true">
<processor class="com.MyUpdateProcessor" />
<processor class="solr.RunUpdateProcessor" />
</updateRequestProcessor>
<!-- Another one -->
<updateRequestProcessor name="alternate">
<processor class="org.apache.solr.ConditionalCopyProcessor" />
<processor class="solr.RunUpdateProcessor" />
<processor class="solr.LogUpdateProcessor" />
</updateRequestProcessor>
{code}
Why do we need factories here? It seems like there is no advantage being added
by multiple factories. If the only advantage is with the factory being able to
choose between instantiating on each request or using an already instantiated
processor then one can argue on having factories for RequestHandlers or
SearchComponents too. The Processors should be created once and re-used. Most
of them are stateless and the others can use the init method and store state in
instance variables. The same is done with RequestHandlers and SearchComponents
at present.
Why should we have a explicit ChainedUpdateRequestProcessorFactory? Seems from
the use-cases that processors will always be chained. Let us have the
implementation do the chaining instead of asking users to add a factory in the
configuration.
Not trying to be critical but seems like this is too complex for the use-cases
it needs to support.
> UpdateRequestProcessorFactory - process requests before submitting them
> -----------------------------------------------------------------------
>
> Key: SOLR-269
> URL: https://issues.apache.org/jira/browse/SOLR-269
> Project: Solr
> Issue Type: New Feature
> Reporter: Ryan McKinley
> Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: SOLR-269-UpdateRequestProcessorFactory.patch,
> SOLR-269-UpdateRequestProcessorFactory.patch,
> SOLR-269-UpdateRequestProcessorFactory.patch, UpdateProcessor.patch
>
>
> A simple UpdateRequestProcessor was added to a bloated SOLR-133 commit.
> An UpdateRequestProcessor lets clients plug in logic after a document has
> been parsed and before it has been 'updated' with the index. This is a good
> place to add custom logic for:
> * transforming the document fields
> * fine grained authorization (can user X updated document Y?)
> * allow update, but not delete (by query?)
> <requestHandler name="/update" class="solr.StaxUpdateRequestHandler" >
> <str
> name="update.processor.class">org.apache.solr.handler.UpdateRequestProcessor</str>
> <lst name="update.processor.args">
> ... (optionally pass in arguments to the factory init method) ...
> </lst>
> </requestHandler>
> http://www.nabble.com/Re%3A-svn-commit%3A-r547495---in--lucene-solr-trunk%3A-example-solr-conf-solrconfig.xml-src-java-org-apache-solr-handler-StaxUpdateRequestHandler.java-src-java-org-apache-solr-handler-UpdateRequestProcessor.jav-tf3950072.html#a11206583
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
