I also strongly advocate a pluggble persistant implementation as users may have a very wide variety of choices for their backend.
I agree with Rafeal, and we need to have a very simple persistant API. But then again O/R mappers are in style and end users may prefer things like hibernate, ibatis etc.. And they maybe convinent to work with. But keeping performance in mind it maybe handy to be close to the data base as much as possible with raw SQL. Another layer in btw means more mapping. How about a proposal on the wiki about the abstraction layer? Regards, Rajith On 9/7/06, Carl Trieloff <[EMAIL PROTECTED]> wrote:
Frank, It looks like it would be very simple to create a module that support JDBC for the Java side. This would mean that anyone can use anything they chose. I would think this would be a great first step, and then add specific additional modules for other OSS BD's projects if desired. Carl. Juergen Donnerstag wrote: > May I suugest that you make it as pluggable as possible to allow for > other implementations (whatever that will be). > > Juergen > > On 9/6/06, Frank Lynch <[EMAIL PROTECTED]> wrote: >> I'd like to start working on a persistence solution for Qpid that will >> be compatible with our apache licensed implementation. I've been >> thinking about iBatis + Derby for this. I like the flexibility that >> iBatis brings, as it allows users to tweak the database table >> format/schema if necessary and its easy to slot in an enterprise >> strength database (like Oracle, Sybase etc) in leiu of Derby. >> >> Has anyone any opinions or thoughts on this, or should I just start >> hacking away at an iBatis based persistence implementation? >> cheers, >> --Frank >> >>
