[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510518
]
Yonik Seeley commented on SOLR-269:
-----------------------------------
> This all works nicely with a simple 'transform' chain.
I don't see any code allowing initialization of the transform chain, or
anything like that.
What are you proposing?
I think it gets tougher when one talks about updates rather than document adds
too.
> Isn't logging best configured with standard java.util.logging settings?
Not if you want a different type... for example, you seemed to want timing
per-document added for example.
Having log specific configuration (such as number of ids to log in a big add)
in it's own processor seems slightly nicer too.
Is there a downside to the logging being separated out in this case? I really
don't have strong feelings about it though (as long as we can keep the default
version lean enough).
> I see what you are getting at, but makes the basic cases more complicated
> then it needs to be.
Yes, with the upside that we know our transform interface isn't too limiting.
> I'm reluctant to add another plugin layer
Me too... which is why just doing transform with the processors seems desirable
(one less type of plugin).
If transformations are not to be done with UpdateRequestProcessor, I'm not sure
we should expose that interface at all as it's tightly coupled with DUH2.
It seems we really only need one type of plugin to do these document
transformations.
> SolrCore could have a single UpdateRequestProcessorFactory that handlers
> could use as the default.
Yes, with update processors, the needed interface to add a document changes...
you need the processor rather than the update handler.
> 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.
