[ https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510774 ]
Ryan McKinley commented on SOLR-269: ------------------------------------ > It's a single call per hook: > if (next != null) next.processAdd(); > Ok. I'm convinced. > > I'm not sure about the named processors... are they needed? > It seems like we need a "standard" one that is used by default everywhere, > and then *maybe* we need to be able to change them per-handler. Do we need > this up front, or could it be deferred? I'm not sure. The only reason I think we *may* want to do it now is to keep the initialization standard and in a single place. If we declare a default processor and have each handler optionally initialize their own, the config may look different. RequestHandlers only have access to a NamedList while initialized, they can't (without serious changes) declare something like: <requestHandler ...> <updateProcessor class="" /> </requestHandler> With that in mind, I think it best to build the updateProcessors using the standard PluginLoader framework and then have RequestHandlers access them by name. > >> Otherwise I'll look at how to make UpdateRequestProcessorFactory[] feel more >> palatable. > > That could be wrapped in another UpdateRequestProcessorFactory if desired... > it doesn't matter much if the impl is hidden by a class or a method IMO. Ok, I'll start with UpdateProcessor.patch and fold in my changes. > 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, 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.