lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-2857) Multi-content-type /update handler
Date Mon, 31 Oct 2011 11:07:32 GMT


Erik Hatcher commented on SOLR-2857:

Rather than building this around delegating to other update handlers, I'd rather see it built
at least using pluggable ContentStreamLoader's.  The granularity is that a ContentStreamLoader
is per-stream, whereas the current ContentStreamHandlerBase extending classes handle the full
request and all content streams.  I envision a general purpose /update being able to hand
each stream off to different loaders, rather than simply delegate the whole request to a handler.

Then we tie loaders to content-type's as a solrconfig plugin kinda thing, with of course our
built-in ones auto-registered.  Perhaps we even add an "ContentType[] accepts(SolrQueryRequest
req)" (where ContentType is just a String maybe?, req param desired?) to ContentStreamLoader
so that content loaders can be auto-registered to the types they accept?  Maybe then we need
ContentStreamLoaderFactory's to get these things constructed from solrconfig with params?
 Looks like all ContentStreamLoader's also use UpdateRequestProcessor so that looks like a
candidate to pull up to the base class, eh?

... just thinking out loud.
> Multi-content-type /update handler
> ----------------------------------
>                 Key: SOLR-2857
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Erik Hatcher
>             Fix For: 4.0
> Something I've been thinking about lately... it'd be great to get rid of all the specific
update handlers like /update/csv, /update/extract, and /update/json and collapse them all
into a single /update that underneath uses the content-type(s) to hand off to specific content
handlers.  This would make it much easier to toss content at Solr and provide a single entry
point for updates.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message