[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509737
]
Yonik Seeley commented on SOLR-269:
-----------------------------------
> I need something that is easily subclassed and can cleanly holds state across
> an entire request cycle.
Having a factory and separate object so that one can use core instead of
req.getCore(), etc, seems like overkill for the normal case though since
getCore(), getSchema(), getUpdateHandler() all just return instance variables.
I was thinking any state like that could be on the UpdateCommand.
I'd like to have potentially several request processors, but if people start
doing single doc add requests, instantiating and initializing all those request
processors will get expensive.
I do see your usecase though, in the case of multiple docs per add and you have
some expensive state you only want to calculate once.
If it's a relatively rare case, one could put it in the request context.
The tradeoff would be an extra hash lookup per-document of a multi-document add
vs an extra object creation for single-doc adds.
Different Q on usage: is this where my document mutator stuff should go??? If
I want a transformation done on a field, regardless of where the data is coming
from (XML update handler, CSV update handler, future REST update handler, etc),
how should that be done? Is there a single place I can register a plugin to do
this, and is UpdateRequestProcessor where you see it happening?
> 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
>
>
> 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.
