[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510506
]
Ryan McKinley commented on SOLR-269:
------------------------------------
> - conditional copyField, field transformations (between multiple fields
> too... something Analyzer can't do), loading certain fields from a database
> if missing,
> updating a related document, etc.
>
This all works nicely with a simple 'transform' chain.
>> Is the LogUpdateRequestProcessor just an example?
>
> IMO, it's a default since no logging is done by the
> ChangeUpdateRequestProcessor (anyone think of a better name for that?).
> Then in a Benchmarking section of the Solr Wiki, we could advise to remove
> logging altogether. Or you could remove the ChangeUpdateRequestProcessor to
> skip index
> changes to better benchmark hotspots in the parsing + doc creation phase, etc.
>
Isn't logging best configured with standard java.util.logging settings? If
necessary, the base processor could check if the logging level is high enough
to keep track of somethings.
For benchmarking, don't we just want a single noop processor?
>> The one compelling chained use case I can think of is for document
>> transformation
>
> Ah, I briefly looked at SOLR-139 when you mentioned it before, but missed the
> transformer stuff.
> In a way multiple update processors are more generic and wide open... you
> could actually insert two documents into the index for each doc added,
> you could do transforms on the actual Lucene document (add Field options that
> Solr doesn't currently support, etc.
>
I see what you are getting at, but makes the basic cases more complicated then
it needs to be. I have been considering UpdateRequestProcessor as an
'advanced' option where changing their behavior is writing custom code -- not
text configuration.
In the advanced case where you want to build multiple documents or munge the
actual Lucene document existing it may be more difficult to live in a chain
rather then have explicit control. If
I think the cleanest design would be a single entry point and keeping the real
functionality in easily subclassed functions or utility classes. The latest
SOLR-139 tries that (but it could still use some cleanup)
> 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,
> 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.
