Re: Should I extend DIH to handle POST too?

: I guess I got the wrong impression initially. These classes extend the : RequestHandlerBase. your confusion is totally understandable, and stemms from some confusion legacy naming convention. there is an UpdateHandler API which is a low level API for dictating how changes are made to the

Re: Should I extend DIH to handle POST too?

Hi Noble, I started digging into the code to this and came away a bit confused - apologize being 'quite a newbie' here. The solrconfig contains both an Update Handler and an Update Request Handler Should I plug in the former or the latter. I am not sure I want to replace the 'high

Re: Should I extend DIH to handle POST too?

Do not replace any update handler. There are already a handful of updatehandlers Just add another . Take a look at XmlUpdateRequestHandler, CSVRequestHandler, BinaryUpdateRequestHandler etc you can define them as a request handler eq: requestHandler name=/update/myhandler

Re: Should I extend DIH to handle POST too?

Thanks, I guess I got the wrong impression initially. These classes extend the RequestHandlerBase. Since you mentioned we need to extend the ContenStreamBase, I was thinking that we need to create a new plugin for the ContentStream that would be picked up by the XmlUpdateRequestHandler

Re: Should I extend DIH to handle POST too?

That does not look like a great option. DIH looks like an overkill for this usecase. You can write a simple UpdateHandler to do that . All that you need to do is to extent ContentStreamHandlerBase and register it as an UpdateHandler On Sat, Jan 24, 2009 at 12:34 PM, Shalin Shekhar Mangar

Should I extend DIH to handle POST too?

Hi I had earlier described my requirement of needing to 'post XMLs as-is' to SOLR and have it handled just as the DIH would do on import using the mapping in data-config.xml. I got multiple answers for the 'post approach' - the top two being - Use SOLR CELL - Use SOLRJ In general I