You can. DAO code is designed to be decoupled from the db connection it uses. DB connection contained within the Transaction object which is a context object carried throughout a thread. You can switch the db connection that Transaction connects to by calling open and give it a db id.
--Alex > -----Original Message----- > From: Will Chan [mailto:will.c...@citrix.com] > Sent: Wednesday, August 15, 2012 5:33 PM > To: cloudstack-dev@incubator.apache.org > Subject: RE: Hibernate -> Custom DAO for AWS component > > 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.da...@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.batt...@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:dar...@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.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?
