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" class="com.foo.MyUpdateHandler" /> On Tue, Jan 27, 2009 at 4:04 AM, Gunaranjan Chandraraju <chandrar...@apple.com> wrote: > 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 performance' updateHandler. > If it is the "Update Request Handler" level then I saw that the current > XMLRequestHandler iterates through a list of content streams and calls the > processor for each of them. > So when you mentioned the ContentStreamBase below, I was wondering if the > advise was for me to add such 'content stream' that gives my transformed XML > to the XmlUpdateRequestHandler and then the logic flows as before inside > XMLRequestHandler. (not sure where to plugin such a content stream). > > I am sorry if these are very trivial questions, but I was unsure of which > part of the architecture to plug-in without 'reinventing the wheel'. While > I want to plug-in on the server side, don't want to do that > redoing/reinventing too much code. I want to plug in at the highest level > so that future enhancements will work as-is for us? > > Regards > Guna > > On Jan 24, 2009, at 12:42 AM, Noble Paul നോബിള് नोब्ळ् wrote: > >> 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 >> <shalinman...@gmail.com> wrote: >>> >>> There's another option. Using DIH with Solrj. Take a look at: >>> >>> https://issues.apache.org/jira/browse/SOLR-853 >>> >>> There's a patch there but it hasn't been updated to trunk. A contribution >>> would be most welcome. >>> >>> On Sat, Jan 24, 2009 at 3:11 AM, Gunaranjan Chandraraju < >>> chandrar...@apple.com> wrote: >>> >>>> 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 would like to keep all the 'data conversion' inside the >>>> SOLR >>>> powered search system rather than having clients do the XSL and >>>> transforming >>>> the XML before sending them (CELL approach). >>>> >>>> My question is? How should I design this >>>> - Tomcat Servlet that provides this 'post' endpoint. Accepts the XML >>>> over >>>> HTTP, transforms it and calls SOLRJ to update. This is the same TOMCAT >>>> that >>>> houses SOLR. >>>> - SOLR Handler (Is this the right way?) >>>> - Take this a step further and implement it as an extension to DIH - a >>>> handler that will refer to DIH data-config xml and use the same >>>> transformation. This way I can invoke an import for 'batched files' or >>>> do a >>>> 'post 'for the same XML with the same data-config mapping being applied. >>>> Maybe it can be a separate handler that just refers to the same >>>> data-config.xml and not necessarily bundled with DIH handler code. >>>> >>>> Looking for some advise. If the DIH extension is the way to go then I >>>> would be happy to extend it and contribute that back to SOLR. >>>> >>>> Regards, >>>> Guna >>>> >>> >>> >>> >>> -- >>> Regards, >>> Shalin Shekhar Mangar. >>> >> >> >> >> -- >> --Noble Paul > > -- --Noble Paul
