[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510009
]
Ryan McKinley commented on SOLR-269:
------------------------------------
> getCore(), getSchema(), getUpdateHandler() all just return instance
> variables.
>
ok, getCore() isn't a good canidate; It is annoying to start every function
with a train wreck: req.getCore().getUpdateHandler()
Having a single class per request makes sense for a subclass I am working with
-- it does some expensive initialization and stores the results. I could put
this in req.getContext()
> instantiating and initializing all those request processors will get
> expensive.
Really? the default initialize is trivial - stuff that would happen at the
beginning of every function anyway. I suppose GC could be an issue
> I do see your usecase though, in the case of multiple docs per add and you
> have some expensive state you only want to calculate once.
In r552986, I changed the logging to match solr 1.2 -- this required
accumulating the id's and spitting them out at the end. In 1.2 with processing
and parsing entwined, this was just a giant loop. To get the same behavior we
need to stash it somewhere...
> Different Q on usage: is this where my document mutator stuff should go???
Yes. The intent is to have a simple place between document parsing and
indexing where you can do whatever you need to do. Any parsing strategy
(XML,JSON,etc) could share the same processor.
Looking at SOLR-139, I now think the most flexible/useful way to support
modifiable documents is to build utility functions for the UpdateProcessor that
can manipulate SolrInputDocuments.
- - -
I will take another crack at SOLR-139 implemented in the UpdateProcessor, then
we should return to the question of singleton vs factory - trying to work with
a more complex processor may make this choice more obvious.
> 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
>
>
> 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.
