incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajesh Battala <>
Subject RE: Hibernate -> Custom DAO for AWS component
Date Tue, 14 Aug 2012 05:45:46 GMT
I will re submit the patch with CloudStack DAO Implementation. Do let me know if there are
concerns with this approach.

Rajesh Battala

-----Original Message-----
From: Darren Shepherd [] 
Sent: Tuesday, August 14, 2012 1:59 AM
Subject: RE: Hibernate -> Custom DAO for AWS component

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?



-------- Original Message --------
Subject: RE: Hibernate -> Custom DAO for AWS component
From: Will Chan <>
Date: Mon, August 13, 2012 12:56 pm
To: ""

> -----Original Message-----
> From: Alex Huang []
> Sent: Monday, August 13, 2012 10:33 AM
> To:
> Subject: RE: Hibernate -> Custom DAO for AWS component
> > -----Original Message-----
> > From: Darren Shepherd []
> > Sent: Sunday, August 12, 2012 8:25 AM
> > To:
> > Subject: Hibernate -> Custom DAO for AWS component
> >
> > All,
> >
> > I was just reviewing 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?
View raw message