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