qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: persistence
Date Fri, 08 Sep 2006 13:56:43 GMT
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?



On 9/7/06, Carl Trieloff <cctrieloff@redhat.com> 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 <frank@iona.com> 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
> >>
> >>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message