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 Thu, 30 Aug 2007 06:31:15 GMT
On 8/29/07, Nicky Sandhu <> wrote:
> gnodet wrote:
> >
> > Btw, I was wondering if a consumer could be implemented for JDBC too:
> > an example would be a polling consumer that polls for rows in a given
> > table
> > and send a message for each new row (we need a strategy to determine if
> > a row is new: it could be deleting processed rows or flagging them
> > somehow)...
> >
> That was the use case I had before I started down this path. I believe I can
> now do something like
>  from("timer:poller?period=10000").setBody("select * from table where
> somecondition is
> true").to("jdbc:myDatasource?readSize=1000").splitter(rowSplitter).process(myprocess);

As I kinda alluded to in a previous mail in this thread; if folks
wanted we could try simplify this DSL statement a bit by using some
way to lookup named queries via the URI. e.g. if we did support
ibatis, or some ibatis like mechanism to make it easy to refer to
named queries to simplify the polling DSL...


this would combine the from(timer).setBody(sql).to(jdbc) to a single
from() statement - at the cost of having a level of indirection for
the SQL; looking it up by name in the Registry or an iBatis mapping
file etc

> Note..I still have to write a row splitter component but that should be easy
> (substitute your own splitting process for now)

I wonder if splitting by row is gonna be such a common use case, we
might wanna enable that as an option by default in the jdbc component?
I guess the issue is what to convert the row to; so I guess we need to
use the DSL to define how to split it and once split, how to convert
the rows into something.

Is there an easy expression to turn a resultset into individual row
objects? (Then we could use ay of the existing expression languages
like EL).

> Now whats missing still above is deleting the processed rows ... that goes
> back to being able to support onComplete or onError ... so once James and
> Hiram stabilize their commits we should be able to wrap a transaction around
> this and in the onComplete part of that do something like
> setBody("delete from table where somecondition is
> true").to("jdbc:myDatasource") or onError do something else

BTW the JPA component does this - its just you've gotta write an
entity bean for your table first which means it does take a bit longer
to get stuff done. The entity bean class name is used to define the
query to poll; then the entity bean is deleted (or updated) when its
been processed.

View raw message