camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: JdbcEndpoint - Consumer
Date Mon, 04 Feb 2008 14:57:22 GMT
On 04/02/2008, Roman Kalukiewicz <roman.kalukiewicz@gmail.com> wrote:
> > in both cases the idea is generally to make a bean to represent a row.
> >
> > We could write an SDO component and use that to avoid the user having
> > to write a bean...
>
> My $0.02 is that it is not very natural what we currently have in jdbc
> component. Event it is, then it is not in sync what we have in other
> components (to compare it with JPA for example). Maybe we should think
> about creating another component that could express database flows
> like this:
>
> from("sql:select a, b, c from d").to("sql:insert into t values :a, :c, :d");

Agreed. The current JDBC component is a bit limited :)


> so we pool a database using some select statement - the result is a
> Map that maps column names to values. Then it could be sent to some
> other sql endpoint that simply could use placeholders to generate
> another query.
>
> This way a sql component should be configured with a DataSource.
>
> What do you think about something like this? I can try to create such
> a component.

Sounds great!

I wonder if SDO is worth looking at to represent the result sets? It
kinda seems a way to wrap up a kinda blob of SQL data, then insert it
somewhere else.

But a simpler version that just used a List of Maps would be fine too :)

There's also that cached RowSet stuff Sun did a while ago; dunno if
folks actually use it though; SDO seemed to be a bit better, but it
might be overkill.
-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

Mime
View raw message