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

Reply via email to