Btw, I was wondering if a consumer could be implemented for JDBC too:
an example would be a polling consumer that polls for rows in a given
table
and send a message for each new row (we need a strategy to determine if
a row is new: it could be deleting processed rows or flagging them
somehow)...
On Aug 29, 2007, at 7:51 PM, Nicky Sandhu wrote:
James.Strachan wrote:
On 8/29/07, Nicky Sandhu <[EMAIL PROTECTED]> wrote:
In my rookie attempt to create the JDBC component
(https://issues.apache.org/activemq/browse/CAMEL-128)
Great stuff BTW! Have applied your patch - keep up the great
work! :)\
Cool. That was quick! It is still evolving so there maybe upcoming
patches.
James.Strachan wrote:
I encountered the
following questions
1. If the exchange out is send out the ResultSet (open cursor)
then is
there
support for a callback on the exchange to allow a lifecycle of
end on the
exchange to allow one to close out the ResultSet. Instead I have
created
a
limit on the read size and copied the data into a list of hash
maps. Not
very efficient and I don't like it much. Any suggestions ?
We're just in the process of adding an onComplete / onFailure
handlers
to the exchange, so you can close things like result sets and the
like.
https://issues.apache.org/activemq/browse/CAMEL-123
Hopefully as soon as those are working we can use 'em
There you go again...keeping one step ahead of me :)
James.Strachan wrote:
3. Lastly the conversion mechanism from result set to other
types. Any
suggestions on whether using the type converter is appropriate
here ?
Yeah - am sure we could think of some useful conversions; maybe to
Lists of Maps or something; or to XML? Maybe the cached JDBC result
set stuff might be useful? Or there's SDO? I've not looked at JDBC 4
yet but IIRC there's some SQL <-> POJO mapping stuff in there too I
think.
List of maps is what it is doing right now. Really once you have
onComplete
available on exchanges I can allow the default of putting the
ResultSet
(read open cursor) on the exchange and refactor this conversion to a
@Converter method. There is of course components like iBatis that work
directly off a ResultSet and I can see implementing a converter
component
like
to("jdbc:...").convertTo(resultSetToObjectMapper) where the mapper
converts
the resultset to custom object using the mappers configuration. A
little
different from the @Converter strategy where there is only one map
possible
between two types and possibly a bit more dynamic (@Converters
loaded at
startup time vs mappers are configured before use)
--
View this message in context: http://www.nabble.com/Camel-JDBC-
Component-tf4348358s22882.html#a12392303
Sent from the Camel - Development mailing list archive at Nabble.com.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
