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