incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Chan <will.c...@citrix.com>
Subject RE: Hibernate -> Custom DAO for AWS component
Date Thu, 16 Aug 2012 00:33:05 GMT
I'm pretty sure you can because the Usage Server connects to both DB and it uses the DAO layer
as well.

Will

> -----Original Message-----
> From: Prachi Damle [mailto:Prachi.Damle@citrix.com]
> Sent: Wednesday, August 15, 2012 5:22 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate -> Custom DAO for AWS component
> 
> One concern here... can we connect to multiple databases using CloudStack
> DAO Implementation?
> 
> The awsapi component needs to connect to two databases - 'cloudbridge'
> db(used for user Auth and S3)  and 'cloud' db  (used by EC2 to pull
> cloudstack configuration/service offering/default zone info) With hibernate
> we could do that.
> 
> -Prachi
> 
> -----Original Message-----
> From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> Sent: Monday, August 13, 2012 10:46 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate -> Custom DAO for AWS component
> 
> I will re submit the patch with CloudStack DAO Implementation. Do let me
> know if there are concerns with this approach.
> 
> Thanks
> Rajesh Battala
> 
> -----Original Message-----
> From: Darren Shepherd [mailto:darren@godaddy.com]
> Sent: Tuesday, August 14, 2012 1:59 AM
> To: cloudstack-dev@incubator.apache.org
> 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?
> 
> Darren
> 
> 
> 
> 
> 
> 
> -------- Original Message --------
> Subject: RE: Hibernate -> Custom DAO for AWS component
> From: Will Chan <will.chan@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.Huang@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:darren@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?
Mime
View raw message