[jira] Commented: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them

["Shalin Shekhar Mangar (JIRA)" <ji...@apache.org>]

    [ 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.