[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510771
]
Yonik Seeley commented on SOLR-269:
-----------------------------------
> The only one I'm not sure about is:
> - explicit flow control between processors for greatest flexibility
It's a single call per hook:
if (next != null) next.processAdd();
And it's exactly what you need for your "buffering" situation.
Chaining is the model that Lucene uses for it's analyzers too (only difference
is that it's a pull instead of a push).
> I'm still trying to avoid the parent UpdateRequestProcessorFactory chain as a
> default behavior. It seems fine as a super-duper custom controlller, but
> unurly in the default/slightly custom case.
I'm not clear on why... the configuration is more complex?
> If you like the general structure / flow of
> SOLR-269-UpdateRequestProcessorFactory.patch
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?
It seems like there does need to be a method on SolrCore to get a
RequestProcessor or Factory, since that becomes
the new interface to do an index change (otherwise you miss the doc
transformations, etc).
> 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.
> 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.
