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