lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McKinley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them
Date Fri, 06 Jul 2007 20:16:06 GMT

    [ https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510774
] 

Ryan McKinley commented on SOLR-269:
------------------------------------


> It's a single call per hook:
>   if (next != null) next.processAdd();
> 

Ok.  I'm convinced.


> 
> I'm not sure about the named processors... are they needed?
> It seems like we need a "standard" one that is used by default everywhere,
> and then *maybe* we need to be able to change them per-handler.  Do we need this up front,
or could it be deferred?

I'm not sure.  The only reason I think we *may* want to do it now is to keep the initialization
standard and in a single place.  If we declare a default processor and have each handler optionally
initialize their own, the config may look different.  RequestHandlers only have access to
a NamedList while initialized, they can't (without serious changes) declare something like:
 <requestHandler ...>
   <updateProcessor class="" />
 </requestHandler>

With that in mind, I think it best to build the updateProcessors using the standard PluginLoader
framework and then have RequestHandlers access them by name.


> 
>> Otherwise I'll look at how to make UpdateRequestProcessorFactory[] feel more palatable.
> 
> That could be wrapped in another UpdateRequestProcessorFactory if desired... it doesn't
matter much if the impl is hidden by a class or a method IMO.

Ok, I'll start with UpdateProcessor.patch and fold in my changes.


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


Mime
View raw message