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] Issue Comment Edited: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them
Date Fri, 25 Jul 2008 16:15:31 GMT

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

ryantxu edited comment on SOLR-269 at 7/25/08 9:14 AM:
-------------------------------------------------------------

bq. A "request" scope will create the chain or individual processor for each request so that
you may maintain state without using request's context. Otherwise, it will be created once
and re-used for all requests. Will that solve this problem?

--To me, that makes it more confusing then having each processor call next() explicitly...--
 (dooh - answering the wrong question)  This gets overly complex too... do we add a special
init() function?  would everything need a factory, but it may or may not be used?

If the motivation for making the objects shared across requests is clarity, i'm not sure it
helps.  Is there some other reason?


bq. In Noble's patch, instead of calling super.processXXX method, you can return true/false
to signal or avoid chaining.

but then how would a processor be able to continue the chain?  Consider the buffering example...
how would I be able to call all buffered functions on finish()?  What if I want a processor
to make sure only one document is sent at a time?


      was (Author: ryantxu):
    bq. A "request" scope will create the chain or individual processor for each request so
that you may maintain state without using request's context. Otherwise, it will be created
once and re-used for all requests. Will that solve this problem?

To me, that makes it more confusing then having each processor call next() explicitly... 


bq. In Noble's patch, instead of calling super.processXXX method, you can return true/false
to signal or avoid chaining.

but then how would a processor be able to continue the chain?  Consider the buffering example...
how would I be able to call all buffered functions on finish()?  What if I want a processor
to make sure only one document is sent at a time?

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