Return-Path: Delivered-To: apmail-activemq-camel-dev-archive@locus.apache.org Received: (qmail 1048 invoked from network); 30 Aug 2007 06:31:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Aug 2007 06:31:45 -0000 Received: (qmail 54443 invoked by uid 500); 30 Aug 2007 06:31:41 -0000 Delivered-To: apmail-activemq-camel-dev-archive@activemq.apache.org Received: (qmail 54424 invoked by uid 500); 30 Aug 2007 06:31:41 -0000 Mailing-List: contact camel-dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: camel-dev@activemq.apache.org Delivered-To: mailing list camel-dev@activemq.apache.org Received: (qmail 54415 invoked by uid 99); 30 Aug 2007 06:31:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2007 23:31:41 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com designates 66.249.82.235 as permitted sender) Received: from [66.249.82.235] (HELO wx-out-0506.google.com) (66.249.82.235) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Aug 2007 06:31:36 +0000 Received: by wx-out-0506.google.com with SMTP id i30so437531wxd for ; Wed, 29 Aug 2007 23:31:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EsY3Dh53cC6Okf04Ky6ckSJYSydzZuR7wQEx/J5/d+hNFF/OUQmtLKldieUUuJQbB75SdJBUpqMAoaoy0E4iOA4evdpCtdJsBuPKDzHJbKP0/FPQnmxbeKahZps3TgKTOo0vQBIGly5egkX38+O+N2Xm6Zz39taQPzqH9yyUSUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Cv2Z544/SjCHfO6HqLQqeNIvyEyNnvOJGFbT3nKuVnXbow5nhwRzCMW+ZsqDEctfyP4zR4z5BI+cpDH37qc/7Myggn7ha0j4HZ2wwdGwO+W59jN01F2jCM+CpNhO/UfP6ZHGMkm7K7bbnR+CqNEw37KSaSz4UHbByEoO1sEdpp0= Received: by 10.90.34.3 with SMTP id h3mr65479agh.1188455475996; Wed, 29 Aug 2007 23:31:15 -0700 (PDT) Received: by 10.90.105.10 with HTTP; Wed, 29 Aug 2007 23:31:15 -0700 (PDT) Message-ID: Date: Thu, 30 Aug 2007 07:31:15 +0100 From: "James Strachan" To: camel-dev@activemq.apache.org Subject: Re: Camel JDBC Component In-Reply-To: <12393157.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <12389082.post@talk.nabble.com> <12392303.post@talk.nabble.com> <80F5AB37-9D48-4F5D-BA0D-20AD4AA72980@worldonline.fr> <12393157.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org 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... from("ibatis:findRecentlyUpdatedOrdersQuery?productName=beer").to("activemq:topic:someTopic") 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. -- James ------- http://macstrac.blogspot.com/