[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616929#action_12616929
]
Shalin Shekhar Mangar commented on SOLR-269:
--------------------------------------------
bq. I think that removing the factories does not simplify things... most
processors that do interesting things will need to parse some request arguments
and keep some state. So they will end up with a separate object that is looked
up in the Context (and created if it's not there and stuffed into the Context).
Same number of classes, but maybe even a little more complex.
How about giving this independence through configuration?
{code:xml}
<updateRequestProcessorChain scope="request">
<processor class="com.MyUpdateProcessor" />
<processor class="solr.RunUpdateProcessor" />
</updateRequestProcessor>
<!-- Another one -->
<updateRequestProcessorChain name="alternate">
<processor class="org.apache.solr.ConditionalCopyProcessor" scope="request" />
<processor class="solr.RunUpdateProcessor" />
<processor class="solr.LogUpdateProcessor" />
</updateRequestProcessorChain>
{code}
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?
bq. We lose power by removing the explicit calling of "next" by components. I
actually have a component that needs to buffer up some documents and pass them
down the chain in batches later. I think Ryan might have something like this
too.
In Noble's patch, instead of calling super.processXXX method, you can return
true/false to signal or avoid chaining.
> 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.
