cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <>
Subject Re: persistence layer
Date Sat, 23 Nov 2013 10:17:41 GMT
Jooq does a good job of handling the differences in dialects so as long as you don't use a
feature specific to a database your are fine.  More info at

I've used jooq across databases and it's been fine.  The sql we use in ACS is quite simple
so supporting multiple DBs will be fine. 


> On Nov 22, 2013, at 2:06 PM, Daan Hoogland <> wrote:
> Had a quick look, It looks alright. One question/doubt: will we thigh
> ourselves more to mysql if we code sql more directly instead of
> abstracting away from it so we can leave db choice to the operator in
> the future!?!?
> On Thu, Nov 21, 2013 at 7:03 AM, Darren Shepherd
> <> wrote:
>> I've done a lot of analysis on the data access layer, but just haven't had time to
put together a discuss/recommendation.  In the end I'd propose we move to jOOQ.  It's an excellent
framework that will be very natural to the style of data access that CloudStack uses and we
can slowly migrate to it.  I've hacked up some code and proven that I can get the two frameworks
to seamlessly interoperate.  So you can select from a custom DAO and commit with jOOQ or vice
versa.  Additionally jOOQ will work with the existing pojos we have today.
>> Check out jOOQ and let me know what you think of it.  I know for most people the
immediate thought would be to move to JPA, but the way we managed "session" is completely
incompatible with JPA and will require constant merging.  Additionally mixing our custom DAO
framework with a JPA solution looks darn near impossible.
>> Darren
>>> On Nov 11, 2013, at 8:33 PM, Laszlo Hornyak <>
>>> Hi,
>>> What are the general directions with the persistence system?
>>> What I know about it is:
>>> - It works with JPA (javax.persistence) annotations
>>> - But rather than integrating a general JPA implementation such us
>>> hibernate, eclipselink or OpenJPA it uses its own query generator and DAO
>>> classes to generate SQL statements.
>>> Questions:
>>> - Are you planing to use JPA? What is the motivation behind the custom DAO
>>> system?
>>> - There are some capabilities in the DAO system that are not used. Should
>>> these capabilities be maintained or is it ok to remove the support for
>>> unused features in small steps?
>>> --
>>> EOF

View raw message