camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Camel JDBC Component
Date Wed, 29 Aug 2007 18:06:32 GMT
On 8/29/07, Nicky Sandhu <> wrote:
> James.Strachan wrote:
> >
> > On 8/29/07, Nicky Sandhu <> wrote:
> >>
> >> In my rookie attempt to create the JDBC component
> >> (
> >
> > 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.
> >
> >
> >
> > 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.


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).



> 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.


View raw message