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

Reply via email to