There are many ways to handle the situation you are trying to accomplish. The idea of using custom components or just plain processors to handle your endpoints could be used. I have had several ETL implementations where I have done just that. You can also use a Scheduler or Timer for the from: endpoint and send them to what you eluded to in your email as using a to: to execute the query with a route. You can also encapsulate the from: in one route and just call direct: to another route using ?block=true if you want to wait on the next execution. With that said, try using some sort of either DAO pattern or custom SQL Invoker class that can be set to your custom component or processor for SQL access. Simply instantiate the SQL class(s) and inject or set them in your Processor or Custom Component.
Well there are a lot of ways to skin this cat but unless there is a well defined problem and requirements there is no real best approach I can think of. Each implementation I have done was based on what is needed to solve the problem and in each case there the solution was different. This one of the nice things about Camel is that there are baked solutions and the ability to create custom solutions. Hope this helps. Chris O. *Chris Odom | Sr Consultant | Media Driver* 512.799.0270 | chris.o...@mediadriver.com 810 Hester's Crossing, Suite 165, Round Rock, TX 78681 On Tue, Sep 16, 2014 at 3:02 PM, Tim Dudgeon <tdudgeon...@gmail.com> wrote: > Hi all! > > I'm needing to write a new Camel Component for accessing a database. I've > looked at the various database related components and see that there is no > consistent pattern among these. I was wondering if there were > recommendations as to what works best. > > So my component would need to be much like a standard SQL database (e.g. > the SQL or JDBC components), but needs to go beyond plain SQL. But in > effect all operations are insert, update, delete and query operations, > really just like SQL, but just not being executed as SQL. > > Logically query operations would map to a from: endpoint and insert, > update and delete to a to: endpoint. But its clear that from: endpoints > can't really carry a payload that would be the query (or its params), so it > looks like its best to handle query using a to: endpoint as well. Or maybe > to support both where simple fixed queries can be part of the from: url > parameters? > > It looks to me like the MongoDB is the most sophisticated component, > allowing the "action" to be defined in the URL params, and gives a lot of > flexibility. But is the best approach? > > All thoughts and experiences welcome. > > Tim >
