cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Travis Graham <tgra...@tgraham.us>
Subject Re: persistence layer
Date Mon, 25 Nov 2013 12:57:06 GMT
MariaDB is a drop in replacement for MySQL, so it can be used with or without the JOOQ changes.

Travis

On Nov 25, 2013, at 5:20 AM, Sebastien Goasguen <runseb@gmail.com> wrote:

> 
> On Nov 23, 2013, at 4:13 PM, Laszlo Hornyak <laszlo.hornyak@gmail.com> wrote:
> 
>> Wouldn't it be a lot of work to move to JOOQ? All queries will have to be
>> rewritten.
>> 
>> 
> 
> An a non-java developer question: Will that help support different databases ? like moving
to MariaDB ?
> 
>> 
>> 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
View raw message