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 (as it iterates
over the content streams). This special ContentStreamBase would
convert our XML to the XML format expected by the existing
XmlUpdateRequestHandler.
My mistake- I will extend the RequestHandlerBase and create a new
RequestHandler.
Regards
Guna
On Jan 26, 2009, at 8:15 PM, Noble Paul നോബിള്
नोब्ळ् wrote:
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
