I think there's two points. 1) Raw SQL is bad, so even in a time crunch moving to the custom CloudStack DAO implementation *should* have been better. 2) I'd rather see a JPA based solution then moving to custom CloudStack DAO.
I think Alex and I agree on point 1, and I'm not sure if anybody agrees with point 2. What's the time frame for when this was supposed to be done? Darren -------- Original Message -------- Subject: RE: Hibernate -> Custom DAO for AWS component From: Will Chan <will.c...@citrix.com> Date: Mon, August 13, 2012 12:56 pm To: "cloudstack-dev@incubator.apache.org" <cloudstack-dev@incubator.apache.org> > -----Original Message----- > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: Monday, August 13, 2012 10:33 AM > To: cloudstack-dev@incubator.apache.org > Subject: RE: Hibernate -> Custom DAO for AWS component > > > > > -----Original Message----- > > From: Darren Shepherd [mailto:dar...@godaddy.com] > > Sent: Sunday, August 12, 2012 8:25 AM > > To: cloudstack-dev@incubator.apache.org > > Subject: Hibernate -> Custom DAO for AWS component > > > > All, > > > > I was just reviewing https://reviews.apache.org/r/6557/diff/ for the > > Hibernate -> Custom DAO implementation and it makes me so sad. Its > > not that you went from Hibernate ORM to custom built ORM (that is > > already in CloudStack), you went from ORM to raw SQL. From the size > > of the diff and the amount of lines of code added, its an > > advertisement in itself in why one would want to use an ORM. > > > > I just joined this mail listing so I probably missed the whole back > > story, but from what I can gather, you can't use hibernate because of > > the license and the consensus is to just make it consistent with > > CloudStack, which already has a custom ORM/DAO implementation. > > > > This comment is probably too late in the game, but I really think your > > missing an opportunity here. For the future of CloudStack I think > > most everyone would agree that it should move to a standard ORM > > approach and drop the custom one it has. Using my "Jump to > > Conclusions Mat" I would say that such a discussion will end up with > > deciding that Spring+JPA should be the interface/container and the > > implementation I don't know (I'd vote Eclipse TopLink if the license is > compatible). > > > > So the AWS component is a perfect place to test out such framework do > > to its isolated nature. Having a lot of experience with hibernate/jpa > > and CloudStack I have a good idea in my mind just how difficult it > > would be to convert all of the CloudStack code to a JPA compatible > > solution. If you were to do the conversion, for practical reasons, > > you are going to have to do a phased migration. This means that you'd > > have to support old framework and new framework concurrently for > > sometime. Coming up with an approach to reconcile the two frameworks > > will take some time and effort. Since the EC2 component is a pretty > > well isolated framework, it would be easy to implement Spring/JPA and > > test the validity of what would be the end state before you take on the > complex and long task of converting all of CloudStack. > > > > I'd even be willing to work on this. It just seems silly to me to go > > from ORM to SQL and then back to ORM. But I realize, as I said > > before, this comment is somewhat late in the game. > > +1. We should not have gone back to using SQL on this. I added this email > to the review for 6557. > > --Alex I had thought the move to this was due to lack of time and wanting to include the AWSAPI support in CS 4.0?
