Chris Hostetter wrote:
: SOLR-133: Adding StaxUpdateRequestHandler.java and mapping it to:
: http://localhost:8983/solr/admin/update/stax
: in the example solrconfig.xml
:
: We should test and evaluate this in comparison to the
: XmlUpdateRequestHandler before replacing it.
an easy way to sanity check this might be to subclass the existing tests
and use the on the fly handler registration to replace the
XmlRequestHandler with the new stax one and make sure all the tests pass.
thats a good idea. I have been testing it by changing the path on my
local config. Subclassing a few tests is a good suggestion. I will do
that.
One question about this (i wasn't really following the jira issue) ... is
To be honest, the JIRA issue got a little bloated and interconnected -
once too many things depend on one another it gets difficult to keep
track of (and keep up to date). It probably makes sense to open a new
issue for UpdateRequestProcessor
there any particular reason why UpdateRequestProcessor is a class
constructed using a request instead of using a factory pattern?
it seems like there might be common "initialization" stuff the
UpdateRequestProcesser might want to do which would make sense in a single
init(NamedList) method that the StaxUpdateRequestHandler was required to
call in it's init method so it can have some state.
A factory pattern would make more sense. Something akin to the
TokenizerFactory - yes, passing requestHandler init args to the factory
makes sense.
Perhaps it is just configuration fatigue, but I was reluctant to make
another registry ;) As I had pictured it, an UpdateRequestHandler would
have a single 'processor' - but i suppose with invariant params, it
could also pick a shared ProcessorFactory.
I am using the UpdateRequestProcessor for document based authorization
(can user X edit document Y?) but we should make sure the design is more
general.
ryan
