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.
