[ 
https://issues.apache.org/jira/browse/SOLR-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140625#comment-13140625
 ] 

Hoss Man commented on SOLR-2857:
--------------------------------

Regardless of the implementation...
{quote}
    * How to distinguish between XML and XSLT updates? Both are 'text/xml'?
    * When would the ExtractingRequestHandler be selected? On all unknown 
types? What if you want to index an XML as verbatim text, but it has the XML 
content type?
    * There should perhaps be a parameter to let you override the 
auto-detection?
{quote}

..these seem like the kinds of situations where you would make an explicit 
request to an explicitly named handler, instead of relying on content-type 
detection (ie: if we remap "/update" to some new snazzier handler, and someone 
says "but i want to do an xslt based update, not an xml update" then they can 
POST to "/update/xslt" instead.  etc....)
                
> 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to