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 <frank.zh...@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 <frank.zh...@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.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
> > > > >
> > >
>
