On 8/29/07, Nicky Sandhu <[EMAIL PROTECTED]> 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.
Great! Patches are always welcome! :) > 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. Great. Am sure for folks who wanna use it, we could use SDO as another POJO holder of the result set etc. e.g. am sure camel-sdo could add converters from ResultSet <-> SDO DataObject stuff etc I guess the sweet spot of SDO is being able to execute any old SQL & turn it into a DataObject then perform expressions on it as a kinda POJO thingy & turn it to/from XML. So either you use a custom mapping to a POJO (JPA or custom Converter or iBatis) - or let SDO slurp it up. Or there's always the List of Maps etc > 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. Yeah. I could imagine us having an iBatis component too; either as a converter from result sets from the jdbc component, or for doing named queries via the URL (where the actual SQL is in some XML config file or something). e.g. from("ibatis:findRecentlyUpdatedOrdersQuery?productName=beer").to("activemq:topic:someTopic") > 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) Yeah; sounds good to me. -- James ------- http://macstrac.blogspot.com/
