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, 13 Jul 2007 04:07:04 GMT

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

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

> the RequestHandler has final say over what Processor gets used

absolutely!  The question is just what do in the default /update case.  I'm inclined to have
the request say what processor to use.  With 'invariants' that can be fixed to a single implementation,
and will let people configure processors without a custom handler.

How do you all feel about the basic structure?  I like the structure, but am not sure how
'public' to make the configuration and implementation.  While it would be nice to keep the
base stuff package protected, then we can't have external configuration and external classes
could not reuse the other bits of the chain (defeating the 'chain' advantages)

I have a pending deadline that depends on input processing and SOLR-139 modifiable documents
-- it would be great to work from a lightly patched trunk rather then a heavily patched one
;)

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


Mime
View raw message