If I read this infinitely long thread correctly, the conclusion is that CloudStack/awsapi needs to be rewritten to use the CloudStack DAO instead of Hibernate. Is that correct?
If so, who is doing this work, and when? That sounds like a big job. Thanks, Ewan. > -----Original Message----- > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: Monday, July 02, 2012 11:31 PM > To: cloudstack-dev@incubator.apache.org > Subject: RE: Hibernate > > Rajesh, > > You should use the existing CloudStack DAO framework. If cloudstack > will move to another ORM framework, it will have to be done in such a > fashion that everything above the DAO layer doesn't have to change and > the majority of the current DAO code do not have to change as well. > Which would mean your code should migrate over along with the rest of > the changes. > > --Alex > > > -----Original Message----- > > From: Rajesh Battala [mailto:rajesh.batt...@citrix.com] > > Sent: Monday, July 02, 2012 10:59 PM > > To: cloudstack-dev@incubator.apache.org > > Subject: RE: Hibernate > > > > > > > > > -----Original Message----- > > > From: Kelven Yang [mailto:kelven.y...@citrix.com] > > > Sent: Saturday, June 30, 2012 3:31 AM > > > To: cloudstack-dev@incubator.apache.org > > > Subject: RE: Hibernate > > > > > > > > > > > > > -----Original Message----- > > > > From: David Nalley [mailto:da...@gnsa.us] > > > > Sent: Friday, June 29, 2012 10:37 AM > > > > To: cloudstack-dev@incubator.apache.org > > > > Subject: Re: Hibernate > > > > > > > > On Fri, Jun 29, 2012 at 12:13 PM, Rajesh Battala > > > > <rajesh.batt...@citrix.com> wrote: > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: David Nalley [mailto:da...@gnsa.us] > > > > >> Sent: Friday, June 29, 2012 8:40 PM > > > > >> To: cloudstack-dev@incubator.apache.org > > > > >> Subject: Re: Hibernate > > > > >> > > > > >> On Fri, Jun 29, 2012 at 9:27 AM, Rajesh Battala > > > > >> <rajesh.batt...@citrix.com> > > > > >> wrote: > > > > >> > > > > > >> > Shall I proceed to replace Hibernate Framework with Spring > JDBC. > > > > >> > > > > > >> > > > > >> This is not a design decision to take lightly, or rush - as > we've > > > > >> talked about replacing the custom ORM that CloudStack uses as > > > > >> well > > > > >> - we'd want to make a decision on something that we are > > > > >> comfortable with > > > > in that role as well. > > > > >> > > > > > [Rajesh Battala] > > > > > So we are planning to implement some ORM framework for > CloudStack > > > also? > > > > > If so, then we need to evaluate the available ORM frameworks > for > > > > > java > > > > which are based on Apache License? > > > > > > > > > > > > > > > > > I don't want to speak for Alex, but I have heard him mention such > a > > > > change number of times, and have seen it in his slides as well. > > > > > > > > But the larger sense is that if we are going to change something > in > > > > AWSAPI for communicating to the database, it should be something > > > > that we are comfortable with adopting in the long term for the > rest > > > > of CloudStack, otherwise we'll end up with two different ways for > > > > connecting to the database, which is fail. > > > > > > For Rajesh's concern in the short term (to get rid of Hibernate), > we > > > basically have following options, > > > 1) Make the project depend on utils.jar in CloudStack and use > existing > > > CloudStack persistent layer. > > > 2) Continue to make CloudBridge project independent > > > a) use direct JDBC > > > b) use Spring JDBC > > > c) use ORM framework on Spring (i.e. OpenJPA etc) > > > > > > I vote on 2-b for a short term resolution. For a couple of reasons, > > > > > > The major reason is for adopting Spring, EC2/S3 API in the future > may > > > both need to support SOAP based web service API and REST API, > Spring > > > comes with support of both, in addition, it provides dependency > > > injection, AOP and pluggable ORM framework, distributed transaction > > management, etc. > > > > > > CloudBridge project has a very simple data model (it has only one > > > table for EC2), original ORM (hibernate) usage is just for > convenience > > > (as Alex pointed that it tried to avoid direct SQL manipulation), > on > > > the other hand, giving the DAO abstraction, a limited amount of > JDBC > > > should not matter too much either. With Spring and already existing > > > DAO abstraction, we can leave bigger ORM decision for the future. > > > > > > In the long term, ORM choice to us seems to be secondary > > > consideration, giving the fact that our current custom ORM > > > implementation serves its purpose well enough in CloudStack. But I > do > > > see the needs of more flexible dependency injection or transaction > > > management framework in order to incorporate better integration > with > > > external transactional systems like message queue servers. I also > see > > > the needs of standardizing AOP patterns used in current CloudStack > > > code base, Spring provides some good answers for that. So there is > a > > > possibility that it will be good for CloudStack to adopt it like > many > > > other Java communities do, so that we can focus on our own business > > > logic and leave these external concerns to people who are doing it > for a > > living. > > > > > > Kelven > > > > > > > > > > > > > > --David > > [Rajesh Battala] > > > > Please let me know conclusion of the thread. > > I didn't see any reply to Kelven suggestions. > > > > Thanks > > Rajesh Battala
