JdbcEndpoint - Consumer

[cmdr <sp...@yahoo.fr>]

It not possible to create a consumer from a jdbcEndPoint.

public Consumer<DefaultExchange> createConsumer(Processor processor) throws
Exception 
{
    throw new RuntimeCamelException("A JDBC Consumer would be the server
side of database! No such support here");
}

What is the best pratice to get data from database and send them as messages
?:confused:
-- 
View this message in context: http://www.nabble.com/JdbcEndpoint---Consumer-tp15183848s22882p15183848.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: JdbcEndpoint - Consumer

[James Strachan <ja...@gmail.com>]

On 04/02/2008, Roman Kalukiewicz <ro...@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

Re: JdbcEndpoint - Consumer

[Roman Kalukiewicz <ro...@gmail.com>]

> 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");

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.

Roman

Re: JdbcEndpoint - Consumer

[James Strachan <ja...@gmail.com>]

On 30/01/2008, cmdr <sp...@yahoo.fr> wrote:
>
> It not possible to create a consumer from a jdbcEndPoint.
>
> public Consumer<DefaultExchange> createConsumer(Processor processor) throws
> Exception
> {
>     throw new RuntimeCamelException("A JDBC Consumer would be the server
> side of database! No such support here");
> }
>
> What is the best pratice to get data from database and send them as messages
> ?:confused:

So the JDBC component basically assumes the body of the message is the
SQL to execute.

If you want to query/poll a database and send messages on you could
use the JPA component...
http://activemq.apache.org/camel/jpa.html

which does exactly that. The idea is you write a JPA entity bean for
the table you want to poll; then when the message is processed, the
row is deleted. (You can use queries and update the entity when its
finished if you prefer).

Another option if you are more comfortable with iBatis than
hibernate/openjpa/toplink is to use the ibatis component...
http://activemq.apache.org/camel/ibatis.html

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

-- 
James
-------
http://macstrac.blogspot.com/

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