cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laszlo Hornyak <laszlo.horn...@gmail.com>
Subject Re: persistence layer
Date Sat, 23 Nov 2013 21:13:09 GMT
Wouldn't it be a lot of work to move to JOOQ? All queries will have to be
rewritten.



On Sat, Nov 23, 2013 at 11:32 AM, Darren Shepherd <
darren.s.shepherd@gmail.com> wrote:

> Going to an ORM is not as simple as you would expect.  First, one can make
> a strong argument that ORM is not the right solution, but that can be
> ignored right now.
>
> You have to look at the context of ACS and figure out what technology is
> the most practical to adopt.  ACS does not have ORM today.  It has a custom
> query api, object mapping, and change tracking for simple CRUD.   Honestly
> these features are quite sufficient for ACS needs.  The problem, and why we
> should change it, is that the current framework is custom, limited in
> functionality, undocumented, and generally a barrier to people developing
> on ACS.  So jOOQ is a somewhat similar approach but it is just far far
> better, has a community of users that have developed over 3-4 years, is
> well documented, and honestly just a very well thought out framework.
>
> Darren
>
> > On Nov 22, 2013, at 6:50 PM, Alex Ough <alex.ough@sungard.com> wrote:
> >
> > All,
> >
> > I'm very interested in converting the current DAO framework to an ORM. I
> > didn't have any experience with java related ORMs, but I've done quite
> lots
> > of works with Django and LINQ. So can you add me if this project is
> started?
> >
> > Thanks
> > Alex Ough
> >
> >
> > On Fri, Nov 22, 2013 at 7:06 AM, Daan Hoogland <daan.hoogland@gmail.com
> >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
> >> <darren.s.shepherd@gmail.com> 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 <laszlo.hornyak@gmail.com
> >
> >> wrote:
> >>>>
> >>>> 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
> >>
> >>
>



-- 

EOF

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