[ 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