You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by David Nalley <da...@gnsa.us> on 2012/06/28 06:42:57 UTC
Hibernate
As you may have seen from an earlier comment on a commit message, the AWS API piece of CloudStack uses Hibernate, which is LGPL licensed, and is thus verboten.
Several issues exist, first, Hibernate is a build dependency at present, not just a runtime dependency. I suppose we could define hibernate as a system requirement, but that seems to be a bit of a stretch.
Based on my reading of [1] it doesn't look like there is a sane way of providing this in the default build short of ripping out Hibernate and replacing it.
So we could make the AWS API bits an optional module to build, and get away with that being a dependency.
In short, I see three options (please comment if you see more)
1. Rip out hibernate and replace with some other ORM
2. Make the AWS API bits an optional non-default part of the build.
3. Declare that hibernate is a system requirement for CloudStack
Thoughts, comments, flames?
--David
[1] http://www.apache.org/legal/3party.html
Re: Hibernate
Posted by David Avenante <d....@gmail.com>.
Have you take a look to monogDB ?
On Thu, Jun 28, 2012 at 2:09 PM, David Nalley <da...@gnsa.us> wrote:
>
>
>
>
> On Jun 28, 2012, at 10:11 AM, Frank Zhang <Fr...@citrix.com> wrote:
>
> > Spring is able to downgrade dependency of hibernate from compile to
> runtime, however, I am surprise at failing to yum search "hibernate" on my
> FC15.
> > Then I did a quick google "hibernate centos rpm" and got nothing.
> > I suggest before digging into Spring, make sure hibernate is distributed
> with popular Linux distribution, otherwise Spring won't help.
> >
>
> This is a very valid point.
> Please use something that is in the mainstream distros if at all possible.
> Moreover this is a decision that should be reached on list as it's
> hopefully further reaching than just the AWS API bits, and I am guessing
> that no one knew about the work you were doing or planning, which is
> problematic in its own right.
>
>
> --David
>
>
>
> >> -----Original Message-----
> >> From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> >> Sent: Wednesday, June 27, 2012 10:44 PM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: RE: Hibernate
> >>
> >> Hi,
> >>
> >> I had started working on this issue. As Hibernate is LGPL we cannot use
> this in
> >> our Apache repo.
> >> I had discussed with Chiradeep and Kelven.
> >>
> >> Am looking at replace Hibernate with Spring Framework
> >> simpleJDBCTemplate.
> >>
> >> The Spring Framework is released under version 2.0 of the Apache License
> >> http://www.springsource.org/spring-framework
> >>
> >> Thanks
> >> Rajesh Battala
> >>
> >>
> >>> -----Original Message-----
> >>> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> >>> Sent: Thursday, June 28, 2012 10:45 AM
> >>> To: cloudstack-dev@incubator.apache.org
> >>> Cc: cloudstack-dev@incubator.apache.org
> >>> Subject: Re: Hibernate
> >>>
> >>> The ORM in the AWS module is 90% used by S3.
> >>> The dependency is mostly abstracted by a DAO layer; there is another
> >>> dependency on transactions. I believe Rajesh B is already working on
> >>> this aspect and there is a bug open on it.
> >>>
> >>> --
> >>> Chiradeep
> >>>
> >>> On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> >>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com>
> >>> wrote:
> >>>>
> >>>>>> In short, I see three options (please comment if you see more) 1.
> >>>>>> Rip out
> >>> hibernate and replace with some other ORM 2. Make the AWS API bits an
> >>> optional non-default part of the build.
> >>>>> 3. Declare that hibernate is a system requirement for CloudStack
> >>>>>
> >>>>> I prefer option #1. It is the cleanest. I don't think it will be
> >>>>> very difficult to
> >>> rip out Hibernate.
> >>>>>
> >>>>> Sheng
> >>>>
> >>>>
> >>>>
> >>>> That is my personal inclination as well, though I am somewhat
> >>>> reticent to
> >>> say so, since I am not doing any of the work to rip and replace. At
> >>> the same time choice of ORM is a big issue. I know, for instance that
> >>> Alex was looking into finding another ORM for the rest of CloudStack.
> >>> When I initially looked at the Hibernate issue, Prachi told me she
> >>> thought it was about 2 weeks worth of work.
> >>>>
> >>>>
> >>>> --David
>
Re: Hibernate
Posted by David Nalley <da...@gnsa.us>.
On Jun 28, 2012, at 10:11 AM, Frank Zhang <Fr...@citrix.com> wrote:
> Spring is able to downgrade dependency of hibernate from compile to runtime, however, I am surprise at failing to yum search "hibernate" on my FC15.
> Then I did a quick google "hibernate centos rpm" and got nothing.
> I suggest before digging into Spring, make sure hibernate is distributed with popular Linux distribution, otherwise Spring won't help.
>
This is a very valid point.
Please use something that is in the mainstream distros if at all possible.
Moreover this is a decision that should be reached on list as it's hopefully further reaching than just the AWS API bits, and I am guessing that no one knew about the work you were doing or planning, which is problematic in its own right.
--David
>> -----Original Message-----
>> From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
>> Sent: Wednesday, June 27, 2012 10:44 PM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: RE: Hibernate
>>
>> Hi,
>>
>> I had started working on this issue. As Hibernate is LGPL we cannot use this in
>> our Apache repo.
>> I had discussed with Chiradeep and Kelven.
>>
>> Am looking at replace Hibernate with Spring Framework
>> simpleJDBCTemplate.
>>
>> The Spring Framework is released under version 2.0 of the Apache License
>> http://www.springsource.org/spring-framework
>>
>> Thanks
>> Rajesh Battala
>>
>>
>>> -----Original Message-----
>>> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
>>> Sent: Thursday, June 28, 2012 10:45 AM
>>> To: cloudstack-dev@incubator.apache.org
>>> Cc: cloudstack-dev@incubator.apache.org
>>> Subject: Re: Hibernate
>>>
>>> The ORM in the AWS module is 90% used by S3.
>>> The dependency is mostly abstracted by a DAO layer; there is another
>>> dependency on transactions. I believe Rajesh B is already working on
>>> this aspect and there is a bug open on it.
>>>
>>> --
>>> Chiradeep
>>>
>>> On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com>
>>> wrote:
>>>>
>>>>>> In short, I see three options (please comment if you see more) 1.
>>>>>> Rip out
>>> hibernate and replace with some other ORM 2. Make the AWS API bits an
>>> optional non-default part of the build.
>>>>> 3. Declare that hibernate is a system requirement for CloudStack
>>>>>
>>>>> I prefer option #1. It is the cleanest. I don't think it will be
>>>>> very difficult to
>>> rip out Hibernate.
>>>>>
>>>>> Sheng
>>>>
>>>>
>>>>
>>>> That is my personal inclination as well, though I am somewhat
>>>> reticent to
>>> say so, since I am not doing any of the work to rip and replace. At
>>> the same time choice of ORM is a big issue. I know, for instance that
>>> Alex was looking into finding another ORM for the rest of CloudStack.
>>> When I initially looked at the Hibernate issue, Prachi told me she
>>> thought it was about 2 weeks worth of work.
>>>>
>>>>
>>>> --David
RE: Hibernate
Posted by Alex Huang <Al...@citrix.com>.
I would recommend against anything that relies on raw SQL. My experiences have been raw SQL has too little tied in to object models and is difficult to maintain.
--Alex
> -----Original Message-----
> From: Frank Zhang [mailto:Frank.Zhang@citrix.com]
> Sent: Thursday, June 28, 2012 10:18 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> Sorry please ignore my former mail
>
> > > Am looking at replace Hibernate with Spring Framework
> > > simpleJDBCTemplate.
> Does this mean ripping out Hibernate? Then we don't have dependency on
> Hibernate anymore.
> I am afraid that AWS API will refactor a bit, as we are jumping from ORM to
> raw JDBC.
>
>
> > -----Original Message-----
> > From: Frank Zhang [mailto:Frank.Zhang@citrix.com]
> > Sent: Thursday, June 28, 2012 10:11 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: Hibernate
> >
> > Spring is able to downgrade dependency of hibernate from compile to
> > runtime, however, I am surprise at failing to yum search "hibernate"
> > on my FC15.
> > Then I did a quick google "hibernate centos rpm" and got nothing.
> > I suggest before digging into Spring, make sure hibernate is
> > distributed with popular Linux distribution, otherwise Spring won't help.
> >
> > > -----Original Message-----
> > > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > > Sent: Wednesday, June 27, 2012 10:44 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: RE: Hibernate
> > >
> > > Hi,
> > >
> > > I had started working on this issue. As Hibernate is LGPL we cannot
> > > use this in our Apache repo.
> > > I had discussed with Chiradeep and Kelven.
> > >
> > > Am looking at replace Hibernate with Spring Framework
> > > simpleJDBCTemplate.
> > >
> > > The Spring Framework is released under version 2.0 of the Apache
> > > License http://www.springsource.org/spring-framework
> > >
> > > Thanks
> > > Rajesh Battala
> > >
> > >
> > > > -----Original Message-----
> > > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > > Sent: Thursday, June 28, 2012 10:45 AM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Cc: cloudstack-dev@incubator.apache.org
> > > > Subject: Re: Hibernate
> > > >
> > > > The ORM in the AWS module is 90% used by S3.
> > > > The dependency is mostly abstracted by a DAO layer; there is
> > > > another dependency on transactions. I believe Rajesh B is already
> > > > working on this aspect and there is a bug open on it.
> > > >
> > > > --
> > > > Chiradeep
> > > >
> > > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang
> > > > > <Sh...@citrix.com>
> > > > wrote:
> > > > >
> > > > >>> In short, I see three options (please comment if you see more) 1.
> > > > >>> Rip out
> > > > hibernate and replace with some other ORM 2. Make the AWS API bits
> > > > an optional non-default part of the build.
> > > > >> 3. Declare that hibernate is a system requirement for
> > > > >> CloudStack
> > > > >>
> > > > >> I prefer option #1. It is the cleanest. I don't think it will
> > > > >> be very difficult to
> > > > rip out Hibernate.
> > > > >>
> > > > >> Sheng
> > > > >
> > > > >
> > > > >
> > > > > That is my personal inclination as well, though I am somewhat
> > > > > reticent to
> > > > say so, since I am not doing any of the work to rip and replace.
> > > > At the same time choice of ORM is a big issue. I know, for
> > > > instance that Alex was looking into finding another ORM for the rest of
> CloudStack.
> > > > When I initially looked at the Hibernate issue, Prachi told me she
> > > > thought it was about 2 weeks worth of work.
> > > > >
> > > > >
> > > > > --David
RE: Hibernate
Posted by Frank Zhang <Fr...@citrix.com>.
Sorry please ignore my former mail
> > Am looking at replace Hibernate with Spring Framework
> > simpleJDBCTemplate.
Does this mean ripping out Hibernate? Then we don't have dependency on Hibernate anymore.
I am afraid that AWS API will refactor a bit, as we are jumping from ORM to raw JDBC.
> -----Original Message-----
> From: Frank Zhang [mailto:Frank.Zhang@citrix.com]
> Sent: Thursday, June 28, 2012 10:11 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> Spring is able to downgrade dependency of hibernate from compile to
> runtime, however, I am surprise at failing to yum search "hibernate" on my
> FC15.
> Then I did a quick google "hibernate centos rpm" and got nothing.
> I suggest before digging into Spring, make sure hibernate is distributed with
> popular Linux distribution, otherwise Spring won't help.
>
> > -----Original Message-----
> > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > Sent: Wednesday, June 27, 2012 10:44 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: Hibernate
> >
> > Hi,
> >
> > I had started working on this issue. As Hibernate is LGPL we cannot
> > use this in our Apache repo.
> > I had discussed with Chiradeep and Kelven.
> >
> > Am looking at replace Hibernate with Spring Framework
> > simpleJDBCTemplate.
> >
> > The Spring Framework is released under version 2.0 of the Apache
> > License http://www.springsource.org/spring-framework
> >
> > Thanks
> > Rajesh Battala
> >
> >
> > > -----Original Message-----
> > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > Sent: Thursday, June 28, 2012 10:45 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Hibernate
> > >
> > > The ORM in the AWS module is 90% used by S3.
> > > The dependency is mostly abstracted by a DAO layer; there is
> > > another dependency on transactions. I believe Rajesh B is already
> > > working on this aspect and there is a bug open on it.
> > >
> > > --
> > > Chiradeep
> > >
> > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com>
> > > wrote:
> > > >
> > > >>> In short, I see three options (please comment if you see more) 1.
> > > >>> Rip out
> > > hibernate and replace with some other ORM 2. Make the AWS API bits
> > > an optional non-default part of the build.
> > > >> 3. Declare that hibernate is a system requirement for CloudStack
> > > >>
> > > >> I prefer option #1. It is the cleanest. I don't think it will be
> > > >> very difficult to
> > > rip out Hibernate.
> > > >>
> > > >> Sheng
> > > >
> > > >
> > > >
> > > > That is my personal inclination as well, though I am somewhat
> > > > reticent to
> > > say so, since I am not doing any of the work to rip and replace. At
> > > the same time choice of ORM is a big issue. I know, for instance
> > > that Alex was looking into finding another ORM for the rest of CloudStack.
> > > When I initially looked at the Hibernate issue, Prachi told me she
> > > thought it was about 2 weeks worth of work.
> > > >
> > > >
> > > > --David
RE: Hibernate
Posted by Frank Zhang <Fr...@citrix.com>.
Spring is able to downgrade dependency of hibernate from compile to runtime, however, I am surprise at failing to yum search "hibernate" on my FC15.
Then I did a quick google "hibernate centos rpm" and got nothing.
I suggest before digging into Spring, make sure hibernate is distributed with popular Linux distribution, otherwise Spring won't help.
> -----Original Message-----
> From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> Sent: Wednesday, June 27, 2012 10:44 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> Hi,
>
> I had started working on this issue. As Hibernate is LGPL we cannot use this in
> our Apache repo.
> I had discussed with Chiradeep and Kelven.
>
> Am looking at replace Hibernate with Spring Framework
> simpleJDBCTemplate.
>
> The Spring Framework is released under version 2.0 of the Apache License
> http://www.springsource.org/spring-framework
>
> Thanks
> Rajesh Battala
>
>
> > -----Original Message-----
> > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > Sent: Thursday, June 28, 2012 10:45 AM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: cloudstack-dev@incubator.apache.org
> > Subject: Re: Hibernate
> >
> > The ORM in the AWS module is 90% used by S3.
> > The dependency is mostly abstracted by a DAO layer; there is another
> > dependency on transactions. I believe Rajesh B is already working on
> > this aspect and there is a bug open on it.
> >
> > --
> > Chiradeep
> >
> > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> >
> > >
> > >
> > >
> > >
> > > On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com>
> > wrote:
> > >
> > >>> In short, I see three options (please comment if you see more) 1.
> > >>> Rip out
> > hibernate and replace with some other ORM 2. Make the AWS API bits an
> > optional non-default part of the build.
> > >> 3. Declare that hibernate is a system requirement for CloudStack
> > >>
> > >> I prefer option #1. It is the cleanest. I don't think it will be
> > >> very difficult to
> > rip out Hibernate.
> > >>
> > >> Sheng
> > >
> > >
> > >
> > > That is my personal inclination as well, though I am somewhat
> > > reticent to
> > say so, since I am not doing any of the work to rip and replace. At
> > the same time choice of ORM is a big issue. I know, for instance that
> > Alex was looking into finding another ORM for the rest of CloudStack.
> > When I initially looked at the Hibernate issue, Prachi told me she
> > thought it was about 2 weeks worth of work.
> > >
> > >
> > > --David
Re: Hibernate
Posted by David Avenante <d....@gmail.com>.
As for a RDBM database the usage of an inverted index is required for
complex query.
Hibernate search is based on lucene (if my memory is good), we use SOLR.
On Thu, Jun 28, 2012 at 9:37 PM, Frank Zhang <Fr...@citrix.com> wrote:
> >
> > Very interesting.
> >
> > So after the read of this explanation and the architecture and coding
> > implication of the usage of Hibernate my question stay the same ....
> >
> > Does the ORM approach based on a relational DB is the good way ?
> > The usage of a Document Oriented Database seem more in adequacy with
> > the problem to solve.
> >
> > No ?
>
> I have to say I haven't dug much into Document DB.
> I simply took a look at key-value store and similar no-sql DB.
> I wonder how does this kind of DB do complicated search? Let's the VM is
> serialized as you said
>
> > > > *{*
> > > > * name: "myVM",*
> > > > * memory: 1024*
> > > > * network: [{eth0: 195.21.24.12}, {eth1: 12.35.15.28}**]*
> > > > * storage: [{local: [{sdb ....}]}]*
> > > > *}*
> > > > *
>
> How can I get the vm whose eth0=195.21.24.12? Does search relay on text
> search engine like Lucent?
>
> >
>
> >
> >
> > On Thu, Jun 28, 2012 at 8:32 PM, Frank Zhang <Fr...@citrix.com>
> > wrote:
> >
> > > Hi David:
> > > I think I can answer part of your question, about graph object.
> > > Actually CloudStack's database entity the xxxVO you see does
> > > have graph object, however it's not using the typical way which is
> > > well known as composition (e.g VMInstance.NetworkVO.NicVO), we use id
> > > which is the primary key in database to composite object graph.
> > > Current popular ORM, Hibernate or JPA, use one-to-many,
> > > many-to-one, many-to-many .... or new annotation(JPA2) like
> > > MapKeyJoinColumn to make object graph transparent just as you
> > mentioned.
> > > However, this doesn't fit CloudStack's requirement in terms of huge
> > > number of objects.
> > > ORM offers to two ways to fetch relational object:
> > > eagerly of lazy. The Eagerly mode definitely won't work for
> > > CloudStack, let me cite an example, assume we have a beautiful graph
> > object hierarchy:
> > > HostVO
> > > |___ VMInstanceVO[]
> > > |_________NicVO[]
> > >
> > > Now once you get a HostVO, you can transparently browse
> > > vms running on it and even get nic information of VM. However, it
> doesn't
> > work.
> > > Let's say you have 10000 hosts, each host run 10 ~ `50 VMs, each VM
> > > has 1 ~ 3 nics. With eager fetching, a listAllHost operation is going
> > > to blow up memory, there are half millions object loaded in memory and
> > > most of them are useless.
> > >
> > > Lazy mode seemingly resolve this problem, however,
> > > Hibernate and JPA only allow lazy load when your entity is still in
> > > persistence context, according to their saying, the object must be
> > > attached. This works pretty well in tradition web application, open
> > > the persistence context when request comes in and close it when
> > > request finishes. However, in CloudStack, a request like DeployVM is
> > > made up of multiple operations such as preparing storage, preparing
> > > network ... some of these operations (e.g. preparing storage) are long
> > > run, it's impossible to keep a persistence opening so long. And most
> > > of operations are based on theadpool where persistence context is hard
> > > to propagate because it's based on threadlocal.
> > > Well, one solution is recommended by hibernate, using detach to remove
> > > entity from persistence and attach it back when needs. IMO, this is a
> > > quite annoying way that brings much trouble to programmer. Let's say I
> > > write a function receiving an entity as parameter:
> > > Void printHost(HostVO vo) {
> > > printVMsonHost(vo.vms)
> > > }
> > > Can somebody tell me the HostVO is attached or detached
> now?
> > > no one knows. You have to call some function of persistence to judge
> > > if the HostVO is attached, if not, attach it back. Otherwise you will
> > > be greeted by a EntityIsNotManaged exception. It ends up with you have
> > > to do boring judge/attach at everywhere you play with entity object
> > > because you don't know if it is attached. Ok, even we don't mind it,
> > > the attach operation is quite annoying. JPA/Hibernate has a method
> > > "detach" entity, but they don't have the opposite method to 'attach'
> > > an entity. Simply google "jpa attach", there are tons of questions
> > > about proper way to re-attach an object back to persistence. The usual
> > > way is to call merge(), but it has the side effect that if you change
> > > the entity accidentally, your change would be written to database,
> this is
> > the source of mysterious bug.
> > >
> > > In CloudStack, you can use id(the primary key of relational
> > > object) to fetch your composition on demand, though it's not as
> > > intuitive as directly wiring whole relational object in code, it does
> > > its job well in practice.
> > >
> > > > -----Original Message-----
> > > > From: David Avenante [mailto:d.avenante@gmail.com]
> > > > Sent: Thursday, June 28, 2012 4:24 PM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Subject: Re: Hibernate
> > > >
> > > > Ok I try ;)
> > > >
> > > > As far I can see in the code the majority of the Object have no
> > > relations and
> > > > are simple VO
> > > >
> > > > Many of object use IMHO a bad pattern (DTO, VO ...)
> > > >
> > > > For example :
> > > >
> > > > public class UserVmVO extends VMInstanceVO implements UserVm { ...
> > > >
> > > > There is NO relation between objects. Object are State.
> > > > *The power of Hibernate is to try for the user to make transparent
> > > > the management of a graph object* *There is NO graph object in
> > > > Cloudstack as far I can see.*
> > > > *
> > > > *
> > > > *In the other side I think the Business Domain of the System
> > > > Management
> > > is
> > > > more document oriented.* *For exemple a VM can be represented by a
> > > > simple JSON structure:*
> > > > *
> > > > *
> > > > *{*
> > > > * name: "myVM",*
> > > > * memory: 1024*
> > > > * network: [{eth0: 195.21.24.12}, {eth1: 12.35.15.28}**]*
> > > > * storage: [{local: [{sdb ....}]}]*
> > > > *}*
> > > > *
> > > > *
> > > > *The force of the approach is to have a schema less support. If we
> > > > need
> > > to
> > > > add attribute to a VM no need to migrate de DB.* *In many case some
> > > > part of the document can be exposed in JSON format directly to the
> > > > view (UI).*
> > > > *
> > > > *
> > > > *We have used MongoDB in on of my project (we used hibernate before)
> > > > and the return in term of usage in very very good.* *In many many
> > > > case,
> > > see
> > > > the data as document is a big win.*
> > > > *
> > > > *
> > > > *
> > > > *
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Jun 28, 2012 at 5:53 PM, Kevin Kluge
> > > > <Ke...@citrix.com>
> > > > wrote:
> > > >
> > > > > Rajesh, can you provide some rationale for this choice versus
> > > > > other options.
> > > > >
> > > > > -kevin
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > > > > > Sent: Wednesday, June 27, 2012 10:44 PM
> > > > > > To: cloudstack-dev@incubator.apache.org
> > > > > > Subject: RE: Hibernate
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I had started working on this issue. As Hibernate is LGPL we
> > > > > > cannot use
> > > > > this in
> > > > > > our Apache repo.
> > > > > > I had discussed with Chiradeep and Kelven.
> > > > > >
> > > > > > Am looking at replace Hibernate with Spring Framework
> > > > > > simpleJDBCTemplate.
> > > > > >
> > > > > > The Spring Framework is released under version 2.0 of the Apache
> > > > > > License http://www.springsource.org/spring-framework
> > > > > >
> > > > > > Thanks
> > > > > > Rajesh Battala
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > > > > > Sent: Thursday, June 28, 2012 10:45 AM
> > > > > > > To: cloudstack-dev@incubator.apache.org
> > > > > > > Cc: cloudstack-dev@incubator.apache.org
> > > > > > > Subject: Re: Hibernate
> > > > > > >
> > > > > > > The ORM in the AWS module is 90% used by S3.
> > > > > > > The dependency is mostly abstracted by a DAO layer; there is
> > > > > > > another dependency on transactions. I believe Rajesh B is
> > > > > > > already working on this aspect and there is a bug open on it.
> > > > > > >
> > > > > > > --
> > > > > > > Chiradeep
> > > > > > >
> > > > > > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us>
> wrote:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang
> > > > > > > > <Sh...@citrix.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >>> In short, I see three options (please comment if you see
> > > > > > > >>> more)
> > > 1.
> > > > > > > >>> Rip out
> > > > > > > hibernate and replace with some other ORM 2. Make the AWS API
> > > > > > > bits an optional non-default part of the build.
> > > > > > > >> 3. Declare that hibernate is a system requirement for
> > > > > > > >> CloudStack
> > > > > > > >>
> > > > > > > >> I prefer option #1. It is the cleanest. I don't think it
> > > > > > > >> will be very difficult to
> > > > > > > rip out Hibernate.
> > > > > > > >>
> > > > > > > >> Sheng
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > That is my personal inclination as well, though I am
> > > > > > > > somewhat reticent to
> > > > > > > say so, since I am not doing any of the work to rip and
> replace.
> > > > > > > At the same time choice of ORM is a big issue. I know, for
> > > > > > > instance that Alex was looking into finding another ORM for
> > > > > > > the
> > > rest of
> > > > CloudStack.
> > > > > > > When I initially looked at the Hibernate issue, Prachi told me
> > > > > > > she thought it was about 2 weeks worth of work.
> > > > > > > >
> > > > > > > >
> > > > > > > > --David
> > > > >
> > >
>
RE: Hibernate
Posted by Kelven Yang <ke...@citrix.com>.
The discussion is going a bit far away from the original topic, CloudBridge project does have certain usage on Hibernate, but it is very minimum. Just less than a dozen of Dao classes needs to be replaced, Rajesh and I had a discussion a while ago, whether to just use direct JDBC or to use JdbcTemplate offered from Spring.
As of the concerns about eager fetch or lazy loading in ORM framework, I'm sure Hibernate or other ORM people can give you a number of good practices you should follow, the same applies to the problem of long application session and short persistent transaction, I know that there are some good practices out there. We seems to argue here some of the most fundamental design principals of ORM layer. These kind of debates seems to belong to Hibernate or other ORM forums
David, your mention about MangoDB usage seems to be very interesting, could you elaborate more details about the problem you were facing and why MangoDB can solve it nicely?
Kelven
> -----Original Message-----
> From: Frank Zhang [mailto:Frank.Zhang@citrix.com]
> Sent: Thursday, June 28, 2012 6:37 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> >
> > Very interesting.
> >
> > So after the read of this explanation and the architecture and coding
> > implication of the usage of Hibernate my question stay the same ....
> >
> > Does the ORM approach based on a relational DB is the good way ?
> > The usage of a Document Oriented Database seem more in adequacy with
> > the problem to solve.
> >
> > No ?
>
> I have to say I haven't dug much into Document DB.
> I simply took a look at key-value store and similar no-sql DB.
> I wonder how does this kind of DB do complicated search? Let's the VM is
> serialized as you said
>
> > > > *{*
> > > > * name: "myVM",*
> > > > * memory: 1024*
> > > > * network: [{eth0: 195.21.24.12}, {eth1: 12.35.15.28}**]*
> > > > * storage: [{local: [{sdb ....}]}]*
> > > > *}*
> > > > *
>
> How can I get the vm whose eth0=195.21.24.12? Does search relay on text
> search engine like Lucent?
>
> >
>
> >
> >
> > On Thu, Jun 28, 2012 at 8:32 PM, Frank Zhang <Fr...@citrix.com>
> > wrote:
> >
> > > Hi David:
> > > I think I can answer part of your question, about graph object.
> > > Actually CloudStack's database entity the xxxVO you see does
> > > have graph object, however it's not using the typical way which is
> > > well known as composition (e.g VMInstance.NetworkVO.NicVO), we use
> > > id which is the primary key in database to composite object graph.
> > > Current popular ORM, Hibernate or JPA, use one-to-many,
> > > many-to-one, many-to-many .... or new annotation(JPA2) like
> > > MapKeyJoinColumn to make object graph transparent just as you
> > mentioned.
> > > However, this doesn't fit CloudStack's requirement in terms of huge
> > > number of objects.
> > > ORM offers to two ways to fetch relational object:
> > > eagerly of lazy. The Eagerly mode definitely won't work for
> > > CloudStack, let me cite an example, assume we have a beautiful graph
> > object hierarchy:
> > > HostVO
> > > |___ VMInstanceVO[]
> > > |_________NicVO[]
> > >
> > > Now once you get a HostVO, you can transparently browse
> > > vms running on it and even get nic information of VM. However, it
> > > doesn't
> > work.
> > > Let's say you have 10000 hosts, each host run 10 ~ `50 VMs, each VM
> > > has 1 ~ 3 nics. With eager fetching, a listAllHost operation is
> > > going to blow up memory, there are half millions object loaded in
> > > memory and most of them are useless.
> > >
> > > Lazy mode seemingly resolve this problem, however,
> > > Hibernate and JPA only allow lazy load when your entity is still in
> > > persistence context, according to their saying, the object must be
> > > attached. This works pretty well in tradition web application, open
> > > the persistence context when request comes in and close it when
> > > request finishes. However, in CloudStack, a request like DeployVM
> > > is made up of multiple operations such as preparing storage,
> > > preparing network ... some of these operations (e.g. preparing
> > > storage) are long run, it's impossible to keep a persistence opening
> > > so long. And most of operations are based on theadpool where
> > > persistence context is hard to propagate because it's based on
> threadlocal.
> > > Well, one solution is recommended by hibernate, using detach to
> > > remove entity from persistence and attach it back when needs. IMO,
> > > this is a quite annoying way that brings much trouble to programmer.
> > > Let's say I write a function receiving an entity as parameter:
> > > Void printHost(HostVO vo) {
> > > printVMsonHost(vo.vms)
> > > }
> > > Can somebody tell me the HostVO is attached or detached
> now?
> > > no one knows. You have to call some function of persistence to
> > > judge if the HostVO is attached, if not, attach it back. Otherwise
> > > you will be greeted by a EntityIsNotManaged exception. It ends up
> > > with you have to do boring judge/attach at everywhere you play with
> > > entity object because you don't know if it is attached. Ok, even we
> > > don't mind it, the attach operation is quite annoying. JPA/Hibernate
> > > has a method "detach" entity, but they don't have the opposite method
> to 'attach'
> > > an entity. Simply google "jpa attach", there are tons of questions
> > > about proper way to re-attach an object back to persistence. The
> > > usual way is to call merge(), but it has the side effect that if you
> > > change the entity accidentally, your change would be written to
> > > database, this is
> > the source of mysterious bug.
> > >
> > > In CloudStack, you can use id(the primary key of
> > > relational
> > > object) to fetch your composition on demand, though it's not as
> > > intuitive as directly wiring whole relational object in code, it
> > > does its job well in practice.
> > >
> > > > -----Original Message-----
> > > > From: David Avenante [mailto:d.avenante@gmail.com]
> > > > Sent: Thursday, June 28, 2012 4:24 PM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Subject: Re: Hibernate
> > > >
> > > > Ok I try ;)
> > > >
> > > > As far I can see in the code the majority of the Object have no
> > > relations and
> > > > are simple VO
> > > >
> > > > Many of object use IMHO a bad pattern (DTO, VO ...)
> > > >
> > > > For example :
> > > >
> > > > public class UserVmVO extends VMInstanceVO implements UserVm { ...
> > > >
> > > > There is NO relation between objects. Object are State.
> > > > *The power of Hibernate is to try for the user to make transparent
> > > > the management of a graph object* *There is NO graph object in
> > > > Cloudstack as far I can see.*
> > > > *
> > > > *
> > > > *In the other side I think the Business Domain of the System
> > > > Management
> > > is
> > > > more document oriented.* *For exemple a VM can be represented by a
> > > > simple JSON structure:*
> > > > *
> > > > *
> > > > *{*
> > > > * name: "myVM",*
> > > > * memory: 1024*
> > > > * network: [{eth0: 195.21.24.12}, {eth1: 12.35.15.28}**]*
> > > > * storage: [{local: [{sdb ....}]}]*
> > > > *}*
> > > > *
> > > > *
> > > > *The force of the approach is to have a schema less support. If we
> > > > need
> > > to
> > > > add attribute to a VM no need to migrate de DB.* *In many case
> > > > some part of the document can be exposed in JSON format directly
> > > > to the view (UI).*
> > > > *
> > > > *
> > > > *We have used MongoDB in on of my project (we used hibernate
> > > > before) and the return in term of usage in very very good.* *In
> > > > many many case,
> > > see
> > > > the data as document is a big win.*
> > > > *
> > > > *
> > > > *
> > > > *
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Jun 28, 2012 at 5:53 PM, Kevin Kluge
> > > > <Ke...@citrix.com>
> > > > wrote:
> > > >
> > > > > Rajesh, can you provide some rationale for this choice versus
> > > > > other options.
> > > > >
> > > > > -kevin
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > > > > > Sent: Wednesday, June 27, 2012 10:44 PM
> > > > > > To: cloudstack-dev@incubator.apache.org
> > > > > > Subject: RE: Hibernate
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I had started working on this issue. As Hibernate is LGPL we
> > > > > > cannot use
> > > > > this in
> > > > > > our Apache repo.
> > > > > > I had discussed with Chiradeep and Kelven.
> > > > > >
> > > > > > Am looking at replace Hibernate with Spring Framework
> > > > > > simpleJDBCTemplate.
> > > > > >
> > > > > > The Spring Framework is released under version 2.0 of the
> > > > > > Apache License http://www.springsource.org/spring-framework
> > > > > >
> > > > > > Thanks
> > > > > > Rajesh Battala
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > > > > > Sent: Thursday, June 28, 2012 10:45 AM
> > > > > > > To: cloudstack-dev@incubator.apache.org
> > > > > > > Cc: cloudstack-dev@incubator.apache.org
> > > > > > > Subject: Re: Hibernate
> > > > > > >
> > > > > > > The ORM in the AWS module is 90% used by S3.
> > > > > > > The dependency is mostly abstracted by a DAO layer; there
> > > > > > > is another dependency on transactions. I believe Rajesh B is
> > > > > > > already working on this aspect and there is a bug open on it.
> > > > > > >
> > > > > > > --
> > > > > > > Chiradeep
> > > > > > >
> > > > > > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us>
> wrote:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang
> > > > > > > > <Sh...@citrix.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >>> In short, I see three options (please comment if you see
> > > > > > > >>> more)
> > > 1.
> > > > > > > >>> Rip out
> > > > > > > hibernate and replace with some other ORM 2. Make the AWS
> > > > > > > API bits an optional non-default part of the build.
> > > > > > > >> 3. Declare that hibernate is a system requirement for
> > > > > > > >> CloudStack
> > > > > > > >>
> > > > > > > >> I prefer option #1. It is the cleanest. I don't think it
> > > > > > > >> will be very difficult to
> > > > > > > rip out Hibernate.
> > > > > > > >>
> > > > > > > >> Sheng
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > That is my personal inclination as well, though I am
> > > > > > > > somewhat reticent to
> > > > > > > say so, since I am not doing any of the work to rip and
> replace.
> > > > > > > At the same time choice of ORM is a big issue. I know, for
> > > > > > > instance that Alex was looking into finding another ORM for
> > > > > > > the
> > > rest of
> > > > CloudStack.
> > > > > > > When I initially looked at the Hibernate issue, Prachi told
> > > > > > > me she thought it was about 2 weeks worth of work.
> > > > > > > >
> > > > > > > >
> > > > > > > > --David
> > > > >
> > >
RE: Hibernate
Posted by Frank Zhang <Fr...@citrix.com>.
>
> Very interesting.
>
> So after the read of this explanation and the architecture and coding
> implication of the usage of Hibernate my question stay the same ....
>
> Does the ORM approach based on a relational DB is the good way ?
> The usage of a Document Oriented Database seem more in adequacy with
> the problem to solve.
>
> No ?
I have to say I haven't dug much into Document DB.
I simply took a look at key-value store and similar no-sql DB.
I wonder how does this kind of DB do complicated search? Let's the VM is serialized as you said
> > > *{*
> > > * name: "myVM",*
> > > * memory: 1024*
> > > * network: [{eth0: 195.21.24.12}, {eth1: 12.35.15.28}**]*
> > > * storage: [{local: [{sdb ....}]}]*
> > > *}*
> > > *
How can I get the vm whose eth0=195.21.24.12? Does search relay on text search engine like Lucent?
>
>
>
> On Thu, Jun 28, 2012 at 8:32 PM, Frank Zhang <Fr...@citrix.com>
> wrote:
>
> > Hi David:
> > I think I can answer part of your question, about graph object.
> > Actually CloudStack's database entity the xxxVO you see does
> > have graph object, however it's not using the typical way which is
> > well known as composition (e.g VMInstance.NetworkVO.NicVO), we use id
> > which is the primary key in database to composite object graph.
> > Current popular ORM, Hibernate or JPA, use one-to-many,
> > many-to-one, many-to-many .... or new annotation(JPA2) like
> > MapKeyJoinColumn to make object graph transparent just as you
> mentioned.
> > However, this doesn't fit CloudStack's requirement in terms of huge
> > number of objects.
> > ORM offers to two ways to fetch relational object:
> > eagerly of lazy. The Eagerly mode definitely won't work for
> > CloudStack, let me cite an example, assume we have a beautiful graph
> object hierarchy:
> > HostVO
> > |___ VMInstanceVO[]
> > |_________NicVO[]
> >
> > Now once you get a HostVO, you can transparently browse
> > vms running on it and even get nic information of VM. However, it doesn't
> work.
> > Let's say you have 10000 hosts, each host run 10 ~ `50 VMs, each VM
> > has 1 ~ 3 nics. With eager fetching, a listAllHost operation is going
> > to blow up memory, there are half millions object loaded in memory and
> > most of them are useless.
> >
> > Lazy mode seemingly resolve this problem, however,
> > Hibernate and JPA only allow lazy load when your entity is still in
> > persistence context, according to their saying, the object must be
> > attached. This works pretty well in tradition web application, open
> > the persistence context when request comes in and close it when
> > request finishes. However, in CloudStack, a request like DeployVM is
> > made up of multiple operations such as preparing storage, preparing
> > network ... some of these operations (e.g. preparing storage) are long
> > run, it's impossible to keep a persistence opening so long. And most
> > of operations are based on theadpool where persistence context is hard
> > to propagate because it's based on threadlocal.
> > Well, one solution is recommended by hibernate, using detach to remove
> > entity from persistence and attach it back when needs. IMO, this is a
> > quite annoying way that brings much trouble to programmer. Let's say I
> > write a function receiving an entity as parameter:
> > Void printHost(HostVO vo) {
> > printVMsonHost(vo.vms)
> > }
> > Can somebody tell me the HostVO is attached or detached now?
> > no one knows. You have to call some function of persistence to judge
> > if the HostVO is attached, if not, attach it back. Otherwise you will
> > be greeted by a EntityIsNotManaged exception. It ends up with you have
> > to do boring judge/attach at everywhere you play with entity object
> > because you don't know if it is attached. Ok, even we don't mind it,
> > the attach operation is quite annoying. JPA/Hibernate has a method
> > "detach" entity, but they don't have the opposite method to 'attach'
> > an entity. Simply google "jpa attach", there are tons of questions
> > about proper way to re-attach an object back to persistence. The usual
> > way is to call merge(), but it has the side effect that if you change
> > the entity accidentally, your change would be written to database, this is
> the source of mysterious bug.
> >
> > In CloudStack, you can use id(the primary key of relational
> > object) to fetch your composition on demand, though it's not as
> > intuitive as directly wiring whole relational object in code, it does
> > its job well in practice.
> >
> > > -----Original Message-----
> > > From: David Avenante [mailto:d.avenante@gmail.com]
> > > Sent: Thursday, June 28, 2012 4:24 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Hibernate
> > >
> > > Ok I try ;)
> > >
> > > As far I can see in the code the majority of the Object have no
> > relations and
> > > are simple VO
> > >
> > > Many of object use IMHO a bad pattern (DTO, VO ...)
> > >
> > > For example :
> > >
> > > public class UserVmVO extends VMInstanceVO implements UserVm { ...
> > >
> > > There is NO relation between objects. Object are State.
> > > *The power of Hibernate is to try for the user to make transparent
> > > the management of a graph object* *There is NO graph object in
> > > Cloudstack as far I can see.*
> > > *
> > > *
> > > *In the other side I think the Business Domain of the System
> > > Management
> > is
> > > more document oriented.* *For exemple a VM can be represented by a
> > > simple JSON structure:*
> > > *
> > > *
> > > *{*
> > > * name: "myVM",*
> > > * memory: 1024*
> > > * network: [{eth0: 195.21.24.12}, {eth1: 12.35.15.28}**]*
> > > * storage: [{local: [{sdb ....}]}]*
> > > *}*
> > > *
> > > *
> > > *The force of the approach is to have a schema less support. If we
> > > need
> > to
> > > add attribute to a VM no need to migrate de DB.* *In many case some
> > > part of the document can be exposed in JSON format directly to the
> > > view (UI).*
> > > *
> > > *
> > > *We have used MongoDB in on of my project (we used hibernate before)
> > > and the return in term of usage in very very good.* *In many many
> > > case,
> > see
> > > the data as document is a big win.*
> > > *
> > > *
> > > *
> > > *
> > >
> > >
> > >
> > >
> > > On Thu, Jun 28, 2012 at 5:53 PM, Kevin Kluge
> > > <Ke...@citrix.com>
> > > wrote:
> > >
> > > > Rajesh, can you provide some rationale for this choice versus
> > > > other options.
> > > >
> > > > -kevin
> > > >
> > > > > -----Original Message-----
> > > > > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > > > > Sent: Wednesday, June 27, 2012 10:44 PM
> > > > > To: cloudstack-dev@incubator.apache.org
> > > > > Subject: RE: Hibernate
> > > > >
> > > > > Hi,
> > > > >
> > > > > I had started working on this issue. As Hibernate is LGPL we
> > > > > cannot use
> > > > this in
> > > > > our Apache repo.
> > > > > I had discussed with Chiradeep and Kelven.
> > > > >
> > > > > Am looking at replace Hibernate with Spring Framework
> > > > > simpleJDBCTemplate.
> > > > >
> > > > > The Spring Framework is released under version 2.0 of the Apache
> > > > > License http://www.springsource.org/spring-framework
> > > > >
> > > > > Thanks
> > > > > Rajesh Battala
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > > > > Sent: Thursday, June 28, 2012 10:45 AM
> > > > > > To: cloudstack-dev@incubator.apache.org
> > > > > > Cc: cloudstack-dev@incubator.apache.org
> > > > > > Subject: Re: Hibernate
> > > > > >
> > > > > > The ORM in the AWS module is 90% used by S3.
> > > > > > The dependency is mostly abstracted by a DAO layer; there is
> > > > > > another dependency on transactions. I believe Rajesh B is
> > > > > > already working on this aspect and there is a bug open on it.
> > > > > >
> > > > > > --
> > > > > > Chiradeep
> > > > > >
> > > > > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang
> > > > > > > <Sh...@citrix.com>
> > > > > > wrote:
> > > > > > >
> > > > > > >>> In short, I see three options (please comment if you see
> > > > > > >>> more)
> > 1.
> > > > > > >>> Rip out
> > > > > > hibernate and replace with some other ORM 2. Make the AWS API
> > > > > > bits an optional non-default part of the build.
> > > > > > >> 3. Declare that hibernate is a system requirement for
> > > > > > >> CloudStack
> > > > > > >>
> > > > > > >> I prefer option #1. It is the cleanest. I don't think it
> > > > > > >> will be very difficult to
> > > > > > rip out Hibernate.
> > > > > > >>
> > > > > > >> Sheng
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > That is my personal inclination as well, though I am
> > > > > > > somewhat reticent to
> > > > > > say so, since I am not doing any of the work to rip and replace.
> > > > > > At the same time choice of ORM is a big issue. I know, for
> > > > > > instance that Alex was looking into finding another ORM for
> > > > > > the
> > rest of
> > > CloudStack.
> > > > > > When I initially looked at the Hibernate issue, Prachi told me
> > > > > > she thought it was about 2 weeks worth of work.
> > > > > > >
> > > > > > >
> > > > > > > --David
> > > >
> >
Re: Hibernate
Posted by David Avenante <d....@gmail.com>.
Very interesting.
So after the read of this explanation and the architecture and coding
implication of the usage of Hibernate
my question stay the same ....
Does the ORM approach based on a relational DB is the good way ?
The usage of a Document Oriented Database seem more in adequacy with the
problem to solve.
No ?
On Thu, Jun 28, 2012 at 8:32 PM, Frank Zhang <Fr...@citrix.com> wrote:
> Hi David:
> I think I can answer part of your question, about graph object.
> Actually CloudStack's database entity the xxxVO you see does have
> graph object, however it's not using the typical way which is well known as
> composition (e.g VMInstance.NetworkVO.NicVO), we use id which is the
> primary key in database to composite object graph.
> Current popular ORM, Hibernate or JPA, use one-to-many,
> many-to-one, many-to-many .... or new annotation(JPA2) like
> MapKeyJoinColumn to make object graph transparent just as you mentioned.
> However, this doesn't fit CloudStack's requirement in terms of huge number
> of objects.
> ORM offers to two ways to fetch relational object: eagerly
> of lazy. The Eagerly mode definitely won't work for CloudStack, let me cite
> an example, assume we have a beautiful graph object hierarchy:
> HostVO
> |___ VMInstanceVO[]
> |_________NicVO[]
>
> Now once you get a HostVO, you can transparently browse vms
> running on it and even get nic information of VM. However, it doesn't work.
> Let's say you have 10000 hosts, each host run 10 ~ `50 VMs, each VM has 1
> ~ 3 nics. With eager fetching, a listAllHost operation is going to blow up
> memory, there are half millions object loaded in memory and most of them
> are useless.
>
> Lazy mode seemingly resolve this problem, however, Hibernate
> and JPA only allow lazy load when your entity is still in persistence
> context, according to their saying, the object must be attached. This
> works pretty well in tradition web application, open the persistence
> context when request comes in and close it when request finishes. However,
> in CloudStack, a request like DeployVM is made up of multiple operations
> such as preparing storage, preparing network ... some of these operations
> (e.g. preparing storage) are long run, it's impossible to keep a
> persistence opening so long. And most of operations are based on theadpool
> where persistence context is hard to propagate because it's based on
> threadlocal.
> Well, one solution is recommended by hibernate, using detach to remove
> entity from persistence and attach it back when needs. IMO, this is a quite
> annoying way that brings much trouble to programmer. Let's say I write a
> function receiving an entity as parameter:
> Void printHost(HostVO vo) {
> printVMsonHost(vo.vms)
> }
> Can somebody tell me the HostVO is attached or detached now?
> no one knows. You have to call some function of persistence to judge if
> the HostVO is attached, if not, attach it back. Otherwise you will be
> greeted by a EntityIsNotManaged exception. It ends up with you have to do
> boring judge/attach at everywhere you play with entity object because you
> don't know if it is attached. Ok, even we don't mind it, the attach
> operation is quite annoying. JPA/Hibernate has a method "detach" entity,
> but they don't have the opposite method to 'attach' an entity. Simply
> google "jpa attach", there are tons of questions about proper way to
> re-attach an object back to persistence. The usual way is to call merge(),
> but it has the side effect that if you change the entity accidentally, your
> change would be written to database, this is the source of mysterious bug.
>
> In CloudStack, you can use id(the primary key of relational
> object) to fetch your composition on demand, though it's not as intuitive
> as directly wiring whole relational object in code, it does its job well in
> practice.
>
> > -----Original Message-----
> > From: David Avenante [mailto:d.avenante@gmail.com]
> > Sent: Thursday, June 28, 2012 4:24 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: Hibernate
> >
> > Ok I try ;)
> >
> > As far I can see in the code the majority of the Object have no
> relations and
> > are simple VO
> >
> > Many of object use IMHO a bad pattern (DTO, VO ...)
> >
> > For example :
> >
> > public class UserVmVO extends VMInstanceVO implements UserVm { ...
> >
> > There is NO relation between objects. Object are State.
> > *The power of Hibernate is to try for the user to make transparent the
> > management of a graph object* *There is NO graph object in Cloudstack as
> > far I can see.*
> > *
> > *
> > *In the other side I think the Business Domain of the System Management
> is
> > more document oriented.* *For exemple a VM can be represented by a
> > simple JSON structure:*
> > *
> > *
> > *{*
> > * name: "myVM",*
> > * memory: 1024*
> > * network: [{eth0: 195.21.24.12}, {eth1: 12.35.15.28}**]*
> > * storage: [{local: [{sdb ....}]}]*
> > *}*
> > *
> > *
> > *The force of the approach is to have a schema less support. If we need
> to
> > add attribute to a VM no need to migrate de DB.* *In many case some part
> > of the document can be exposed in JSON format directly to the view (UI).*
> > *
> > *
> > *We have used MongoDB in on of my project (we used hibernate before)
> > and the return in term of usage in very very good.* *In many many case,
> see
> > the data as document is a big win.*
> > *
> > *
> > *
> > *
> >
> >
> >
> >
> > On Thu, Jun 28, 2012 at 5:53 PM, Kevin Kluge <Ke...@citrix.com>
> > wrote:
> >
> > > Rajesh, can you provide some rationale for this choice versus other
> > > options.
> > >
> > > -kevin
> > >
> > > > -----Original Message-----
> > > > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > > > Sent: Wednesday, June 27, 2012 10:44 PM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Subject: RE: Hibernate
> > > >
> > > > Hi,
> > > >
> > > > I had started working on this issue. As Hibernate is LGPL we cannot
> > > > use
> > > this in
> > > > our Apache repo.
> > > > I had discussed with Chiradeep and Kelven.
> > > >
> > > > Am looking at replace Hibernate with Spring Framework
> > > > simpleJDBCTemplate.
> > > >
> > > > The Spring Framework is released under version 2.0 of the Apache
> > > > License http://www.springsource.org/spring-framework
> > > >
> > > > Thanks
> > > > Rajesh Battala
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > > > Sent: Thursday, June 28, 2012 10:45 AM
> > > > > To: cloudstack-dev@incubator.apache.org
> > > > > Cc: cloudstack-dev@incubator.apache.org
> > > > > Subject: Re: Hibernate
> > > > >
> > > > > The ORM in the AWS module is 90% used by S3.
> > > > > The dependency is mostly abstracted by a DAO layer; there is
> > > > > another dependency on transactions. I believe Rajesh B is already
> > > > > working on this aspect and there is a bug open on it.
> > > > >
> > > > > --
> > > > > Chiradeep
> > > > >
> > > > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang
> > > > > > <Sh...@citrix.com>
> > > > > wrote:
> > > > > >
> > > > > >>> In short, I see three options (please comment if you see more)
> 1.
> > > > > >>> Rip out
> > > > > hibernate and replace with some other ORM 2. Make the AWS API bits
> > > > > an optional non-default part of the build.
> > > > > >> 3. Declare that hibernate is a system requirement for
> > > > > >> CloudStack
> > > > > >>
> > > > > >> I prefer option #1. It is the cleanest. I don't think it will
> > > > > >> be very difficult to
> > > > > rip out Hibernate.
> > > > > >>
> > > > > >> Sheng
> > > > > >
> > > > > >
> > > > > >
> > > > > > That is my personal inclination as well, though I am somewhat
> > > > > > reticent to
> > > > > say so, since I am not doing any of the work to rip and replace.
> > > > > At the same time choice of ORM is a big issue. I know, for
> > > > > instance that Alex was looking into finding another ORM for the
> rest of
> > CloudStack.
> > > > > When I initially looked at the Hibernate issue, Prachi told me she
> > > > > thought it was about 2 weeks worth of work.
> > > > > >
> > > > > >
> > > > > > --David
> > >
>
RE: Hibernate
Posted by Frank Zhang <Fr...@citrix.com>.
Hi David:
I think I can answer part of your question, about graph object.
Actually CloudStack's database entity the xxxVO you see does have graph object, however it's not using the typical way which is well known as composition (e.g VMInstance.NetworkVO.NicVO), we use id which is the primary key in database to composite object graph.
Current popular ORM, Hibernate or JPA, use one-to-many, many-to-one, many-to-many .... or new annotation(JPA2) like MapKeyJoinColumn to make object graph transparent just as you mentioned. However, this doesn't fit CloudStack's requirement in terms of huge number of objects.
ORM offers to two ways to fetch relational object: eagerly of lazy. The Eagerly mode definitely won't work for CloudStack, let me cite an example, assume we have a beautiful graph object hierarchy:
HostVO
|___ VMInstanceVO[]
|_________NicVO[]
Now once you get a HostVO, you can transparently browse vms running on it and even get nic information of VM. However, it doesn't work. Let's say you have 10000 hosts, each host run 10 ~ `50 VMs, each VM has 1 ~ 3 nics. With eager fetching, a listAllHost operation is going to blow up memory, there are half millions object loaded in memory and most of them are useless.
Lazy mode seemingly resolve this problem, however, Hibernate and JPA only allow lazy load when your entity is still in persistence context, according to their saying, the object must be attached. This works pretty well in tradition web application, open the persistence context when request comes in and close it when request finishes. However, in CloudStack, a request like DeployVM is made up of multiple operations such as preparing storage, preparing network ... some of these operations (e.g. preparing storage) are long run, it's impossible to keep a persistence opening so long. And most of operations are based on theadpool where persistence context is hard to propagate because it's based on threadlocal.
Well, one solution is recommended by hibernate, using detach to remove entity from persistence and attach it back when needs. IMO, this is a quite annoying way that brings much trouble to programmer. Let's say I write a function receiving an entity as parameter:
Void printHost(HostVO vo) {
printVMsonHost(vo.vms)
}
Can somebody tell me the HostVO is attached or detached now? no one knows. You have to call some function of persistence to judge if the HostVO is attached, if not, attach it back. Otherwise you will be greeted by a EntityIsNotManaged exception. It ends up with you have to do boring judge/attach at everywhere you play with entity object because you don't know if it is attached. Ok, even we don't mind it, the attach operation is quite annoying. JPA/Hibernate has a method "detach" entity, but they don't have the opposite method to 'attach' an entity. Simply google "jpa attach", there are tons of questions about proper way to re-attach an object back to persistence. The usual way is to call merge(), but it has the side effect that if you change the entity accidentally, your change would be written to database, this is the source of mysterious bug.
In CloudStack, you can use id(the primary key of relational object) to fetch your composition on demand, though it's not as intuitive as directly wiring whole relational object in code, it does its job well in practice.
> -----Original Message-----
> From: David Avenante [mailto:d.avenante@gmail.com]
> Sent: Thursday, June 28, 2012 4:24 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Hibernate
>
> Ok I try ;)
>
> As far I can see in the code the majority of the Object have no relations and
> are simple VO
>
> Many of object use IMHO a bad pattern (DTO, VO ...)
>
> For example :
>
> public class UserVmVO extends VMInstanceVO implements UserVm { ...
>
> There is NO relation between objects. Object are State.
> *The power of Hibernate is to try for the user to make transparent the
> management of a graph object* *There is NO graph object in Cloudstack as
> far I can see.*
> *
> *
> *In the other side I think the Business Domain of the System Management is
> more document oriented.* *For exemple a VM can be represented by a
> simple JSON structure:*
> *
> *
> *{*
> * name: "myVM",*
> * memory: 1024*
> * network: [{eth0: 195.21.24.12}, {eth1: 12.35.15.28}**]*
> * storage: [{local: [{sdb ....}]}]*
> *}*
> *
> *
> *The force of the approach is to have a schema less support. If we need to
> add attribute to a VM no need to migrate de DB.* *In many case some part
> of the document can be exposed in JSON format directly to the view (UI).*
> *
> *
> *We have used MongoDB in on of my project (we used hibernate before)
> and the return in term of usage in very very good.* *In many many case, see
> the data as document is a big win.*
> *
> *
> *
> *
>
>
>
>
> On Thu, Jun 28, 2012 at 5:53 PM, Kevin Kluge <Ke...@citrix.com>
> wrote:
>
> > Rajesh, can you provide some rationale for this choice versus other
> > options.
> >
> > -kevin
> >
> > > -----Original Message-----
> > > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > > Sent: Wednesday, June 27, 2012 10:44 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: RE: Hibernate
> > >
> > > Hi,
> > >
> > > I had started working on this issue. As Hibernate is LGPL we cannot
> > > use
> > this in
> > > our Apache repo.
> > > I had discussed with Chiradeep and Kelven.
> > >
> > > Am looking at replace Hibernate with Spring Framework
> > > simpleJDBCTemplate.
> > >
> > > The Spring Framework is released under version 2.0 of the Apache
> > > License http://www.springsource.org/spring-framework
> > >
> > > Thanks
> > > Rajesh Battala
> > >
> > >
> > > > -----Original Message-----
> > > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > > Sent: Thursday, June 28, 2012 10:45 AM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Cc: cloudstack-dev@incubator.apache.org
> > > > Subject: Re: Hibernate
> > > >
> > > > The ORM in the AWS module is 90% used by S3.
> > > > The dependency is mostly abstracted by a DAO layer; there is
> > > > another dependency on transactions. I believe Rajesh B is already
> > > > working on this aspect and there is a bug open on it.
> > > >
> > > > --
> > > > Chiradeep
> > > >
> > > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang
> > > > > <Sh...@citrix.com>
> > > > wrote:
> > > > >
> > > > >>> In short, I see three options (please comment if you see more) 1.
> > > > >>> Rip out
> > > > hibernate and replace with some other ORM 2. Make the AWS API bits
> > > > an optional non-default part of the build.
> > > > >> 3. Declare that hibernate is a system requirement for
> > > > >> CloudStack
> > > > >>
> > > > >> I prefer option #1. It is the cleanest. I don't think it will
> > > > >> be very difficult to
> > > > rip out Hibernate.
> > > > >>
> > > > >> Sheng
> > > > >
> > > > >
> > > > >
> > > > > That is my personal inclination as well, though I am somewhat
> > > > > reticent to
> > > > say so, since I am not doing any of the work to rip and replace.
> > > > At the same time choice of ORM is a big issue. I know, for
> > > > instance that Alex was looking into finding another ORM for the rest of
> CloudStack.
> > > > When I initially looked at the Hibernate issue, Prachi told me she
> > > > thought it was about 2 weeks worth of work.
> > > > >
> > > > >
> > > > > --David
> >
Re: Hibernate
Posted by David Avenante <d....@gmail.com>.
Ok I try ;)
As far I can see in the code the majority of the Object have no relations
and are simple VO
Many of object use IMHO a bad pattern (DTO, VO ...)
For example :
public class UserVmVO extends VMInstanceVO implements UserVm {
...
There is NO relation between objects. Object are State.
*The power of Hibernate is to try for the user to make transparent the
management of a graph object*
*There is NO graph object in Cloudstack as far I can see.*
*
*
*In the other side I think the Business Domain of the System Management is
more document oriented.*
*For exemple a VM can be represented by a simple JSON structure:*
*
*
*{*
* name: "myVM",*
* memory: 1024*
* network: [{eth0: 195.21.24.12}, {eth1: 12.35.15.28}**]*
* storage: [{local: [{sdb ....}]}]*
*}*
*
*
*The force of the approach is to have a schema less support. If we need to
add attribute to a VM no need to migrate de DB.*
*In many case some part of the document can be exposed in JSON format
directly to the view (UI).*
*
*
*We have used MongoDB in on of my project (we used hibernate before) and
the return in term of usage in very very good.*
*In many many case, see the data as document is a big win.*
*
*
*
*
On Thu, Jun 28, 2012 at 5:53 PM, Kevin Kluge <Ke...@citrix.com> wrote:
> Rajesh, can you provide some rationale for this choice versus other
> options.
>
> -kevin
>
> > -----Original Message-----
> > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > Sent: Wednesday, June 27, 2012 10:44 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: Hibernate
> >
> > Hi,
> >
> > I had started working on this issue. As Hibernate is LGPL we cannot use
> this in
> > our Apache repo.
> > I had discussed with Chiradeep and Kelven.
> >
> > Am looking at replace Hibernate with Spring Framework
> > simpleJDBCTemplate.
> >
> > The Spring Framework is released under version 2.0 of the Apache License
> > http://www.springsource.org/spring-framework
> >
> > Thanks
> > Rajesh Battala
> >
> >
> > > -----Original Message-----
> > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > Sent: Thursday, June 28, 2012 10:45 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Hibernate
> > >
> > > The ORM in the AWS module is 90% used by S3.
> > > The dependency is mostly abstracted by a DAO layer; there is another
> > > dependency on transactions. I believe Rajesh B is already working on
> > > this aspect and there is a bug open on it.
> > >
> > > --
> > > Chiradeep
> > >
> > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com>
> > > wrote:
> > > >
> > > >>> In short, I see three options (please comment if you see more) 1.
> > > >>> Rip out
> > > hibernate and replace with some other ORM 2. Make the AWS API bits an
> > > optional non-default part of the build.
> > > >> 3. Declare that hibernate is a system requirement for CloudStack
> > > >>
> > > >> I prefer option #1. It is the cleanest. I don't think it will be
> > > >> very difficult to
> > > rip out Hibernate.
> > > >>
> > > >> Sheng
> > > >
> > > >
> > > >
> > > > That is my personal inclination as well, though I am somewhat
> > > > reticent to
> > > say so, since I am not doing any of the work to rip and replace. At
> > > the same time choice of ORM is a big issue. I know, for instance that
> > > Alex was looking into finding another ORM for the rest of CloudStack.
> > > When I initially looked at the Hibernate issue, Prachi told me she
> > > thought it was about 2 weeks worth of work.
> > > >
> > > >
> > > > --David
>
RE: Hibernate
Posted by Frank Zhang <Fr...@citrix.com>.
I think now the point is not whether we use Spring.
The problem now is:
1. Using Spring, and using JdbcTemplate, then there is no ORM and we are playing with raw SQL now. And awsapi needs big refactor.
2. Using Spring, with JPA. We have ORM, but awsapi still needs refactor as it currently wires with Hibernate core api. However, the workload is smaller as Hibernate core API is quite similar to JPA.
I definitely vote option 2.
No matter whether using Spring, awsapi have to rework as it wires Hibernate core api which asks compile dependency.
> -----Original Message-----
> From: Kelven Yang [mailto:kelven.yang@citrix.com]
> Sent: Thursday, June 28, 2012 4:00 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> A couple of points,
>
> 1. Spring is under Apache license
> 2. Spring provides pretty good JDBC wrapper like SimpleJdbcTemplate to free
> developers from managing DB connections and JDBC prepared statements
> (We used to run into memory leaking issues with our home-grown JDBC
> wrapper) 3. Transaction management 4. Spring is open and easy to plug in 3rd
> party ORM modules 5. You also get Spring AOP for free.
>
> Kelven
>
>
> > -----Original Message-----
> > From: Kevin Kluge [mailto:Kevin.Kluge@citrix.com]
> > Sent: Thursday, June 28, 2012 2:54 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: Hibernate
> >
> > Rajesh, can you provide some rationale for this choice versus other
> > options.
> >
> > -kevin
> >
> > > -----Original Message-----
> > > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > > Sent: Wednesday, June 27, 2012 10:44 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: RE: Hibernate
> > >
> > > Hi,
> > >
> > > I had started working on this issue. As Hibernate is LGPL we cannot
> > > use this in our Apache repo.
> > > I had discussed with Chiradeep and Kelven.
> > >
> > > Am looking at replace Hibernate with Spring Framework
> > > simpleJDBCTemplate.
> > >
> > > The Spring Framework is released under version 2.0 of the Apache
> > > License http://www.springsource.org/spring-framework
> > >
> > > Thanks
> > > Rajesh Battala
> > >
> > >
> > > > -----Original Message-----
> > > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > > Sent: Thursday, June 28, 2012 10:45 AM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Cc: cloudstack-dev@incubator.apache.org
> > > > Subject: Re: Hibernate
> > > >
> > > > The ORM in the AWS module is 90% used by S3.
> > > > The dependency is mostly abstracted by a DAO layer; there is
> > > > another dependency on transactions. I believe Rajesh B is already
> > > > working on this aspect and there is a bug open on it.
> > > >
> > > > --
> > > > Chiradeep
> > > >
> > > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang
> > > > > <Sh...@citrix.com>
> > > > wrote:
> > > > >
> > > > >>> In short, I see three options (please comment if you see more) 1.
> > > > >>> Rip out
> > > > hibernate and replace with some other ORM 2. Make the AWS API bits
> > > > an optional non-default part of the build.
> > > > >> 3. Declare that hibernate is a system requirement for
> > > > >> CloudStack
> > > > >>
> > > > >> I prefer option #1. It is the cleanest. I don't think it will
> > > > >> be very difficult to
> > > > rip out Hibernate.
> > > > >>
> > > > >> Sheng
> > > > >
> > > > >
> > > > >
> > > > > That is my personal inclination as well, though I am somewhat
> > > > > reticent to
> > > > say so, since I am not doing any of the work to rip and replace.
> > > > At the same time choice of ORM is a big issue. I know, for
> > > > instance that Alex was looking into finding another ORM for the
> > > > rest of
> > CloudStack.
> > > > When I initially looked at the Hibernate issue, Prachi told me she
> > > > thought it was about 2 weeks worth of work.
> > > > >
> > > > >
> > > > > --David
RE: Hibernate
Posted by Kelven Yang <ke...@citrix.com>.
A couple of points,
1. Spring is under Apache license
2. Spring provides pretty good JDBC wrapper like SimpleJdbcTemplate to free developers from managing DB connections and JDBC prepared statements (We used to run into memory leaking issues with our home-grown JDBC wrapper)
3. Transaction management
4. Spring is open and easy to plug in 3rd party ORM modules
5. You also get Spring AOP for free.
Kelven
> -----Original Message-----
> From: Kevin Kluge [mailto:Kevin.Kluge@citrix.com]
> Sent: Thursday, June 28, 2012 2:54 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> Rajesh, can you provide some rationale for this choice versus other
> options.
>
> -kevin
>
> > -----Original Message-----
> > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > Sent: Wednesday, June 27, 2012 10:44 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: Hibernate
> >
> > Hi,
> >
> > I had started working on this issue. As Hibernate is LGPL we cannot
> > use this in our Apache repo.
> > I had discussed with Chiradeep and Kelven.
> >
> > Am looking at replace Hibernate with Spring Framework
> > simpleJDBCTemplate.
> >
> > The Spring Framework is released under version 2.0 of the Apache
> > License http://www.springsource.org/spring-framework
> >
> > Thanks
> > Rajesh Battala
> >
> >
> > > -----Original Message-----
> > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > Sent: Thursday, June 28, 2012 10:45 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Hibernate
> > >
> > > The ORM in the AWS module is 90% used by S3.
> > > The dependency is mostly abstracted by a DAO layer; there is
> > > another dependency on transactions. I believe Rajesh B is already
> > > working on this aspect and there is a bug open on it.
> > >
> > > --
> > > Chiradeep
> > >
> > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com>
> > > wrote:
> > > >
> > > >>> In short, I see three options (please comment if you see more) 1.
> > > >>> Rip out
> > > hibernate and replace with some other ORM 2. Make the AWS API bits
> > > an optional non-default part of the build.
> > > >> 3. Declare that hibernate is a system requirement for CloudStack
> > > >>
> > > >> I prefer option #1. It is the cleanest. I don't think it will be
> > > >> very difficult to
> > > rip out Hibernate.
> > > >>
> > > >> Sheng
> > > >
> > > >
> > > >
> > > > That is my personal inclination as well, though I am somewhat
> > > > reticent to
> > > say so, since I am not doing any of the work to rip and replace. At
> > > the same time choice of ORM is a big issue. I know, for instance
> > > that Alex was looking into finding another ORM for the rest of
> CloudStack.
> > > When I initially looked at the Hibernate issue, Prachi told me she
> > > thought it was about 2 weeks worth of work.
> > > >
> > > >
> > > > --David
RE: Hibernate
Posted by Alex Huang <Al...@citrix.com>.
>
>
> Shall I proceed to replace Hibernate Framework with Spring JDBC.
>
We should rethink anything that requires raw SQL. Even object queries would be better. At least eclipse has a way to tell you that the query and the actual object have diverged.
--Alex
RE: Hibernate
Posted by Alex Huang <Al...@citrix.com>.
> 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 the longer term of ORM layer for CloudStack, I think we should look at it as follows.
- CloudStack's contract to the DB are in the VO objects and the JPA annotations.
- JPA should continue to be CloudStack's meta language for the DB schema. There is good support on eclipse for JPA and is well known enough now.
- CloudStack Orchestration Layer will probably not deviate from the current DAO implementations. CloudStack Orchestration Layer needs direct access to DB for locking and ensuring atomicity and the current framework has been efficient in providing that and has been bug free for a long time. In my experience, other frameworks provide too much functionality and too easy to bring about mistakes.
- However, the majority of DB access is not in CloudStack Orchestration Layer. It is in the CloudStack REST API and business logic. For those, we will be refactoring and we need to decide on an a search framework to use. Currently, it uses the same DAO layer that CloudStack Orchestration Layer uses and that's incorrect. The custom DAO layer was never meant to be used as a generic search framework. This effort involves building indexes (perhaps lucene) and work in terms of response objects that are often multiple joins of tables. We should start a discussion on that on a different thread.
- When CloudStack calls plugins, the transaction it uses terminates. All objects sent to and returned by plugins should be sanitized by interfaces or pure pojos. Plugins need to ensure their own operations are idempotent and does not rely on transactions started by CloudStack to roll back states. Therefore, plugins are free to pick their own ORM. CloudStack will provide a recommendation on the ORM implementation to use but it's up to the choice of the developer.
--Alex
Re: Hibernate
Posted by Adrian Cole <ad...@gmail.com>.
Having worked with the cloudbridge, and experimented ripping out soap, s3,
duplicated or unreferenced code, the module becomes quite small, apart from
generated classes. There is hardly any state, and certainly not highly
relational state.
What I'm getting at is that I see no reason to make small things that have
a fighting chance to be succinct at some point, to be bogged down with
inheriting machinery from cloudstack core.
The irony is that most of the bridge is modular or decoupled, even if not
packaged well, and at the same time we discuss architecture to reduce
coupling in the monster code, we are increasing coupling in this!
Cloud bridge persistence, at least ec2, can largely be solved by a Map.
Moving to any heavier persistence layer by default seems overkill to me. I
think any heavy integration should be a plugin, (and in fact cloudstack API
integration should be! *).
Long way of saying let's not get too concerned about making cloudbridge
follow patterns we have doubts about anyway, and instead use that effort to
clean it up.
My 2p
-A
* aside, but EC2Engine should be an interface, etc. Right now, unit testing
is pretty non existent.
On Aug 9, 2012 8:14 AM, "David Nalley" <da...@gnsa.us> wrote:
> Rajesh, is this done?
>
> --David
>
> On Mon, Jul 16, 2012 at 11:49 PM, Rajesh Battala
> <ra...@citrix.com> wrote:
> > Yes Ewan, I would be doing this work.
> >
> > Thanks
> > Rajesh Battala
> >
> >> -----Original Message-----
> >> From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> >> Sent: Tuesday, July 17, 2012 9:03 AM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: RE: Hibernate
> >>
> >> OK, good. So it's a small job. So is Rajesh doing that?
> >>
> >> Ewan.
> >>
> >> > -----Original Message-----
> >> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> >> > Sent: 16 July 2012 17:03
> >> > To: cloudstack-dev@incubator.apache.org
> >> > Subject: RE: Hibernate
> >> >
> >> > My understanding is it's one table and is already wrapped by a DAO.
> >> > The DAO object uses hibernate underneath. Don't think it's a big job.
> >> >
> >> > --Alex
> >> >
> >> > > -----Original Message-----
> >> > > From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> >> > > Sent: Monday, July 16, 2012 4:43 PM
> >> > > To: cloudstack-dev@incubator.apache.org
> >> > > Subject: RE: Hibernate
> >> > >
> >> > > 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.Huang@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.battala@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.yang@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:david@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
> >> > > > > > > <ra...@citrix.com> wrote:
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > >> -----Original Message-----
> >> > > > > > > >> From: David Nalley [mailto:david@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
> >> > > > > > > >> <ra...@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
> >
>
RE: Hibernate
Posted by Rajesh Battala <ra...@citrix.com>.
Am working on it.
Done removing EC2 from Hibernate dependency. Committed the patch locally and testing is almost done.
Will send patch for the same by tomorrow.
Removing Hibernate dependency in S3 project is going on. I would be sending the patch for it by end of this week.
Thanks
Rajesh Battala
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Thursday, August 09, 2012 8:43 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Hibernate
Rajesh, is this done?
--David
On Mon, Jul 16, 2012 at 11:49 PM, Rajesh Battala <ra...@citrix.com> wrote:
> Yes Ewan, I would be doing this work.
>
> Thanks
> Rajesh Battala
>
>> -----Original Message-----
>> From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
>> Sent: Tuesday, July 17, 2012 9:03 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: RE: Hibernate
>>
>> OK, good. So it's a small job. So is Rajesh doing that?
>>
>> Ewan.
>>
>> > -----Original Message-----
>> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
>> > Sent: 16 July 2012 17:03
>> > To: cloudstack-dev@incubator.apache.org
>> > Subject: RE: Hibernate
>> >
>> > My understanding is it's one table and is already wrapped by a DAO.
>> > The DAO object uses hibernate underneath. Don't think it's a big job.
>> >
>> > --Alex
>> >
>> > > -----Original Message-----
>> > > From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
>> > > Sent: Monday, July 16, 2012 4:43 PM
>> > > To: cloudstack-dev@incubator.apache.org
>> > > Subject: RE: Hibernate
>> > >
>> > > 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.Huang@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.battala@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.yang@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:david@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
>> > > > > > > <ra...@citrix.com> wrote:
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >> -----Original Message-----
>> > > > > > > >> From: David Nalley [mailto:david@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
>> > > > > > > >> <ra...@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
>
Re: Hibernate
Posted by David Nalley <da...@gnsa.us>.
Rajesh, is this done?
--David
On Mon, Jul 16, 2012 at 11:49 PM, Rajesh Battala
<ra...@citrix.com> wrote:
> Yes Ewan, I would be doing this work.
>
> Thanks
> Rajesh Battala
>
>> -----Original Message-----
>> From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
>> Sent: Tuesday, July 17, 2012 9:03 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: RE: Hibernate
>>
>> OK, good. So it's a small job. So is Rajesh doing that?
>>
>> Ewan.
>>
>> > -----Original Message-----
>> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
>> > Sent: 16 July 2012 17:03
>> > To: cloudstack-dev@incubator.apache.org
>> > Subject: RE: Hibernate
>> >
>> > My understanding is it's one table and is already wrapped by a DAO.
>> > The DAO object uses hibernate underneath. Don't think it's a big job.
>> >
>> > --Alex
>> >
>> > > -----Original Message-----
>> > > From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
>> > > Sent: Monday, July 16, 2012 4:43 PM
>> > > To: cloudstack-dev@incubator.apache.org
>> > > Subject: RE: Hibernate
>> > >
>> > > 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.Huang@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.battala@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.yang@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:david@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
>> > > > > > > <ra...@citrix.com> wrote:
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >> -----Original Message-----
>> > > > > > > >> From: David Nalley [mailto:david@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
>> > > > > > > >> <ra...@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
>
RE: Hibernate
Posted by Rajesh Battala <ra...@citrix.com>.
Yes Ewan, I would be doing this work.
Thanks
Rajesh Battala
> -----Original Message-----
> From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> Sent: Tuesday, July 17, 2012 9:03 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> OK, good. So it's a small job. So is Rajesh doing that?
>
> Ewan.
>
> > -----Original Message-----
> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > Sent: 16 July 2012 17:03
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: Hibernate
> >
> > My understanding is it's one table and is already wrapped by a DAO.
> > The DAO object uses hibernate underneath. Don't think it's a big job.
> >
> > --Alex
> >
> > > -----Original Message-----
> > > From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> > > Sent: Monday, July 16, 2012 4:43 PM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: RE: Hibernate
> > >
> > > 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.Huang@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.battala@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.yang@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:david@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
> > > > > > > <ra...@citrix.com> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >> -----Original Message-----
> > > > > > > >> From: David Nalley [mailto:david@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
> > > > > > > >> <ra...@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
RE: Hibernate
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
OK, good. So it's a small job. So is Rajesh doing that?
Ewan.
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: 16 July 2012 17:03
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> My understanding is it's one table and is already wrapped by a DAO.
> The DAO object uses hibernate underneath. Don't think it's a big job.
>
> --Alex
>
> > -----Original Message-----
> > From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> > Sent: Monday, July 16, 2012 4:43 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: Hibernate
> >
> > 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.Huang@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.battala@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.yang@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:david@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
> > > > > > <ra...@citrix.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > >> -----Original Message-----
> > > > > > >> From: David Nalley [mailto:david@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
> > > > > > >> <ra...@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
RE: Hibernate
Posted by Alex Huang <Al...@citrix.com>.
My understanding is it's one table and is already wrapped by a DAO. The DAO object uses hibernate underneath. Don't think it's a big job.
--Alex
> -----Original Message-----
> From: Ewan Mellor [mailto:Ewan.Mellor@eu.citrix.com]
> Sent: Monday, July 16, 2012 4:43 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> 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.Huang@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.battala@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.yang@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:david@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
> > > > > <ra...@citrix.com> wrote:
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: David Nalley [mailto:david@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
> > > > > >> <ra...@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
RE: Hibernate
Posted by Ewan Mellor <Ew...@eu.citrix.com>.
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.Huang@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.battala@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.yang@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:david@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
> > > > <ra...@citrix.com> wrote:
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: David Nalley [mailto:david@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
> > > > >> <ra...@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
RE: Hibernate
Posted by Alex Huang <Al...@citrix.com>.
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.battala@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.yang@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:david@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
> > > <ra...@citrix.com> wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: David Nalley [mailto:david@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
> > > >> <ra...@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
RE: Hibernate
Posted by Rajesh Battala <ra...@citrix.com>.
> -----Original Message-----
> From: Kelven Yang [mailto:kelven.yang@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:david@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
> > <ra...@citrix.com> wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: David Nalley [mailto:david@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
> > >> <ra...@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
RE: Hibernate
Posted by Kelven Yang <ke...@citrix.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@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
> <ra...@citrix.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: David Nalley [mailto:david@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
> >> <ra...@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
Re: Hibernate
Posted by David Nalley <da...@gnsa.us>.
On Fri, Jun 29, 2012 at 12:13 PM, Rajesh Battala
<ra...@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: David Nalley [mailto:david@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 <ra...@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.
--David
RE: Hibernate
Posted by Rajesh Battala <ra...@citrix.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@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 <ra...@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?
> --David
Re: Hibernate
Posted by David Nalley <da...@gnsa.us>.
On Fri, Jun 29, 2012 at 9:27 AM, Rajesh Battala
<ra...@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.
--David
RE: Hibernate
Posted by Rajesh Battala <ra...@citrix.com>.
Hi Kevin,
1. The reasons why I had choose Spring JDBC are, it will take care of the below action items very well
The Spring JDBC template allows to clean-up the resources automatically, e.g. release the database connections.
The Spring JDBC template converts the standard JDBC SQLExceptions into RuntimeExceptions. This allows the programmer to react more flexible to the errors. The Spring JDBC template converts also the vendor specific error messages into better understandable error messages.
The Spring JDBC template offers several ways to query the database. queryForList() returns a list of HashMaps. The name of the column is the key in the hashmap for the values in the table.
More convenient is the usage of ResultSetExtractor or RowMapper which allows to translates the SQL result direct into an object (ResultSetExtractor) or a list of objects (RowMapper).
2. Spring is free and it's based on Apache License. We can use spring jars in our repos.
Shall I proceed to replace Hibernate Framework with Spring JDBC.
Thanks
Rajesh Battala
> -----Original Message-----
> From: Kevin Kluge [mailto:Kevin.Kluge@citrix.com]
> Sent: Friday, June 29, 2012 3:24 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> Rajesh, can you provide some rationale for this choice versus other options.
>
> -kevin
>
> > -----Original Message-----
> > From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> > Sent: Wednesday, June 27, 2012 10:44 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: Hibernate
> >
> > Hi,
> >
> > I had started working on this issue. As Hibernate is LGPL we cannot
> > use this in our Apache repo.
> > I had discussed with Chiradeep and Kelven.
> >
> > Am looking at replace Hibernate with Spring Framework
> > simpleJDBCTemplate.
> >
> > The Spring Framework is released under version 2.0 of the Apache
> > License http://www.springsource.org/spring-framework
> >
> > Thanks
> > Rajesh Battala
> >
> >
> > > -----Original Message-----
> > > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > > Sent: Thursday, June 28, 2012 10:45 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Cc: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Hibernate
> > >
> > > The ORM in the AWS module is 90% used by S3.
> > > The dependency is mostly abstracted by a DAO layer; there is
> > > another dependency on transactions. I believe Rajesh B is already
> > > working on this aspect and there is a bug open on it.
> > >
> > > --
> > > Chiradeep
> > >
> > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com>
> > > wrote:
> > > >
> > > >>> In short, I see three options (please comment if you see more) 1.
> > > >>> Rip out
> > > hibernate and replace with some other ORM 2. Make the AWS API bits
> > > an optional non-default part of the build.
> > > >> 3. Declare that hibernate is a system requirement for CloudStack
> > > >>
> > > >> I prefer option #1. It is the cleanest. I don't think it will be
> > > >> very difficult to
> > > rip out Hibernate.
> > > >>
> > > >> Sheng
> > > >
> > > >
> > > >
> > > > That is my personal inclination as well, though I am somewhat
> > > > reticent to
> > > say so, since I am not doing any of the work to rip and replace. At
> > > the same time choice of ORM is a big issue. I know, for instance
> > > that Alex was looking into finding another ORM for the rest of
> CloudStack.
> > > When I initially looked at the Hibernate issue, Prachi told me she
> > > thought it was about 2 weeks worth of work.
> > > >
> > > >
> > > > --David
RE: Hibernate
Posted by Kevin Kluge <Ke...@citrix.com>.
Rajesh, can you provide some rationale for this choice versus other options.
-kevin
> -----Original Message-----
> From: Rajesh Battala [mailto:rajesh.battala@citrix.com]
> Sent: Wednesday, June 27, 2012 10:44 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Hibernate
>
> Hi,
>
> I had started working on this issue. As Hibernate is LGPL we cannot use this in
> our Apache repo.
> I had discussed with Chiradeep and Kelven.
>
> Am looking at replace Hibernate with Spring Framework
> simpleJDBCTemplate.
>
> The Spring Framework is released under version 2.0 of the Apache License
> http://www.springsource.org/spring-framework
>
> Thanks
> Rajesh Battala
>
>
> > -----Original Message-----
> > From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> > Sent: Thursday, June 28, 2012 10:45 AM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: cloudstack-dev@incubator.apache.org
> > Subject: Re: Hibernate
> >
> > The ORM in the AWS module is 90% used by S3.
> > The dependency is mostly abstracted by a DAO layer; there is another
> > dependency on transactions. I believe Rajesh B is already working on
> > this aspect and there is a bug open on it.
> >
> > --
> > Chiradeep
> >
> > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> >
> > >
> > >
> > >
> > >
> > > On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com>
> > wrote:
> > >
> > >>> In short, I see three options (please comment if you see more) 1.
> > >>> Rip out
> > hibernate and replace with some other ORM 2. Make the AWS API bits an
> > optional non-default part of the build.
> > >> 3. Declare that hibernate is a system requirement for CloudStack
> > >>
> > >> I prefer option #1. It is the cleanest. I don't think it will be
> > >> very difficult to
> > rip out Hibernate.
> > >>
> > >> Sheng
> > >
> > >
> > >
> > > That is my personal inclination as well, though I am somewhat
> > > reticent to
> > say so, since I am not doing any of the work to rip and replace. At
> > the same time choice of ORM is a big issue. I know, for instance that
> > Alex was looking into finding another ORM for the rest of CloudStack.
> > When I initially looked at the Hibernate issue, Prachi told me she
> > thought it was about 2 weeks worth of work.
> > >
> > >
> > > --David
RE: Hibernate
Posted by Rajesh Battala <ra...@citrix.com>.
Hi,
I had started working on this issue. As Hibernate is LGPL we cannot use this in our Apache repo.
I had discussed with Chiradeep and Kelven.
Am looking at replace Hibernate with Spring Framework simpleJDBCTemplate.
The Spring Framework is released under version 2.0 of the Apache License http://www.springsource.org/spring-framework
Thanks
Rajesh Battala
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Thursday, June 28, 2012 10:45 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: cloudstack-dev@incubator.apache.org
> Subject: Re: Hibernate
>
> The ORM in the AWS module is 90% used by S3.
> The dependency is mostly abstracted by a DAO layer; there is another
> dependency on transactions. I believe Rajesh B is already working on this
> aspect and there is a bug open on it.
>
> --
> Chiradeep
>
> On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
>
> >
> >
> >
> >
> > On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com>
> wrote:
> >
> >>> In short, I see three options (please comment if you see more) 1. Rip out
> hibernate and replace with some other ORM 2. Make the AWS API bits an
> optional non-default part of the build.
> >> 3. Declare that hibernate is a system requirement for CloudStack
> >>
> >> I prefer option #1. It is the cleanest. I don't think it will be very difficult to
> rip out Hibernate.
> >>
> >> Sheng
> >
> >
> >
> > That is my personal inclination as well, though I am somewhat reticent to
> say so, since I am not doing any of the work to rip and replace. At the same
> time choice of ORM is a big issue. I know, for instance that Alex was looking
> into finding another ORM for the rest of CloudStack. When I initially looked at
> the Hibernate issue, Prachi told me she thought it was about 2 weeks worth
> of work.
> >
> >
> > --David
Re: Hibernate
Posted by Chiradeep Vittal <Ch...@citrix.com>.
The ORM in the AWS module is 90% used by S3.
The dependency is mostly abstracted by a DAO layer; there is another dependency on transactions. I believe Rajesh B is already working on this aspect and there is a bug open on it.
--
Chiradeep
On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
>
>
>
>
> On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com> wrote:
>
>>> In short, I see three options (please comment if you see more) 1. Rip out hibernate and replace with some other ORM 2. Make the AWS API bits an optional non-default part of the build.
>> 3. Declare that hibernate is a system requirement for CloudStack
>>
>> I prefer option #1. It is the cleanest. I don't think it will be very difficult to rip out Hibernate.
>>
>> Sheng
>
>
>
> That is my personal inclination as well, though I am somewhat reticent to say so, since I am not doing any of the work to rip and replace. At the same time choice of ORM is a big issue. I know, for instance that Alex was looking into finding another ORM for the rest of CloudStack. When I initially looked at the Hibernate issue, Prachi told me she thought it was about 2 weeks worth of work.
>
>
> --David
Re: Hibernate
Posted by David Nalley <da...@gnsa.us>.
On Jun 28, 2012, at 12:45 AM, Sheng Liang <Sh...@citrix.com> wrote:
>> In short, I see three options (please comment if you see more) 1. Rip out hibernate and replace with some other ORM 2. Make the AWS API bits an optional non-default part of the build.
> 3. Declare that hibernate is a system requirement for CloudStack
>
> I prefer option #1. It is the cleanest. I don't think it will be very difficult to rip out Hibernate.
>
> Sheng
That is my personal inclination as well, though I am somewhat reticent to say so, since I am not doing any of the work to rip and replace. At the same time choice of ORM is a big issue. I know, for instance that Alex was looking into finding another ORM for the rest of CloudStack. When I initially looked at the Hibernate issue, Prachi told me she thought it was about 2 weeks worth of work.
--David
RE: Hibernate
Posted by Sheng Liang <Sh...@citrix.com>.
> In short, I see three options (please comment if you see more) 1. Rip out hibernate and replace with some other ORM 2. Make the AWS API bits an optional non-default part of the build.
3. Declare that hibernate is a system requirement for CloudStack
I prefer option #1. It is the cleanest. I don't think it will be very difficult to rip out Hibernate.
Sheng