[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616483#action_12616483
]
Ryan McKinley commented on SOLR-269:
------------------------------------
bq. Not trying to be critical but seems like this is too complex for the
use-cases it needs to support.
Nonsense -- the more review / feedback / critique we get, the better --
especially *before* a release :)
"Why do we need factories here?" -- the model came from how things work with
Token/Filter factories. Many processors need to maintain state within a
request. Check the 'log' processor. I have one that checks if the user has
permission on *everything* in the request before executing the commands. We
could have something that keeps track of what it did and backs out the changes
if there is an error. If each processor were shared across all requests, any
state access would need to be synchronized and have some Map<Request,State>
that seems to get ugly pretty fast.
Why ChainedUpdateRequestProcessorFactory? I see your point here. I think we
can force everything to be 'chained' -- The original implementation was not
chained, but then the functional parts got split into their own components and
chained together. Removing the parent chained factory could simplify the whole
thing.
> 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.
