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 >> >>
