[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616520#action_12616520
]
Shalin Shekhar Mangar commented on SOLR-269:
--------------------------------------------
bq. 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.
But we do have SolrQueryRequest#getContext to handle those cases, don't we?
IMHO, we should not force users to write a factory class for each processor
when the benefit is minimal and easy workarounds exist. Please correct me if
I'm misunderstanding something.
bq. Nonsense - the more review / feedback / critique we get, the better -
especially before a release :)
Glad to hear that, though I realize that I'm a year late and that we are very
close to a release :)
It's just that I set out to use this API and had to jump around for quite a
while to figure out how to use it and how it works. I was quite surprised to
find the actual chaining happening in a class which is named
NoOpUpdateProcessor -- though it made sense to me later. Also, it took me a
while to find the wiki page for this feature because it is not linked off the
main page (or the update xml/csv pages). I could find it because I knew that a
class named UpdateRequestProcessor existed. We should link it off the main page
so that it can be found more easily.
> 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.
