On Nov 23, 2013, at 4:13 PM, Laszlo Hornyak <laszlo.horn...@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.sheph...@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.o...@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.hoogl...@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.sheph...@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.horn...@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
