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.avena...@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 <kevin.kl...@citrix.com>
> wrote:
>
> > Rajesh, can you provide some rationale for this choice versus other
> > options.
> >
> > -kevin
> >
> > > -----Original Message-----
> > > From: Rajesh Battala [mailto:rajesh.batt...@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.vit...@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
> > > > > <sheng.li...@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
> >
