[
https://issues.apache.org/jira/browse/SOLR-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140064#comment-13140064
]
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: https://issues.apache.org/jira/browse/SOLR-2857
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
