Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc)

Help

Home

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Hibernate-CDO

Show: Today's Messages :: Show Polls :: Message Navigator

Hibernate-CDO [message #111824]

Wed, 06 February 2008 06:02

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Eike,
I can see that there is code to initialize a cdopackage from an ecore string. I remember you said
that the cdo-server did not depend on emf. This means that the initialization of the cdopackage from
an ecore string is always used on the client, right?

Regarding persisting the cdopackageimpl through hibernate. Hibernate requires a class to have a
no-arg constructor. In addition it is easier if the members are all settable/gettable through
accessors. I have attached a patch to the bugzilla for this.

Some other smaller questions:
- Would it be possible to set the CDOPackageManager in the CDOPackage in the
CDOPackageManager.addPackage method instead of in the constructor? Then the persistence layer (when
reading the cdopackage from the db) does not need to do that.
- What is the purpose of CDOClassProxy?
- What is the purpose of the CDOIDMetaRange?

One other thing I noticed in EMFUtil is that you use a direct XMIResource to do the translation. I
am not sure if this works if you have multiple epackages which refer to eachother. Afaik to get this
working correctly a resourceset should always be used so that the lookups for other packages are
done through the epackageregistry.

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: Hibernate-CDO [message #111839 is a reply to message #111824]

Wed, 06 February 2008 10:04

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Martin Taal wrote:
> Hi Eike,
> I can see that there is code to initialize a cdopackage from an ecore
string. I remember you said
> that the cdo-server did not depend on emf. This means that the
initialization of the cdopackage from
> an ecore string is always used on the client, right?
No, I fear that not. There might be a ctor/setter to fill the ecore String
field of CDOPackageImpl. But there are no means on the server to to turn
this String into a CDOPackage instance. We could easily turn the String
into an EPackage instance in the HibernateStore plugin. But do we really
need to turn that one into a CDOPackageImpl?

> Regarding persisting the cdopackageimpl through hibernate. Hibernate
requires a class to have a
> no-arg constructor. In addition it is easier if the members are all
settable/gettable through
> accessors. I have attached a patch to the bugzilla for this.
I saw it and applied/committed the patch already.

> Some other smaller questions:
> - Would it be possible to set the CDOPackageManager in the CDOPackage in the
> CDOPackageManager.addPackage method instead of in the constructor? Then the
persistence layer (when
> reading the cdopackage from the db) does not need to do that.
Isn't there a separate setPackageManage() method anyway? I recall that
it's needed during a commit operation where there is temporarily used a
TransactionalPackageManager which is later replaced by the usual
SessionPackageManager.

> - What is the purpose of CDOClassProxy?
IIRC it is a wrapper for a CDOClass and/or a CDOClassRef. There are
situations where there is for a certain period only a CDOClassRef
available (e.g. SuperType refs while receiving/storing a CDOPackage) and
later the CDOClassRef can be resolved to a CDOClass. CDOClassProxy makes
it a bit easier for the rest of the framework to handle these 2 distinct
cases.

> - What is the purpose of the CDOIDMetaRange?
Each EModelElement has an own CDOID, a meta ID. There are some
EModelElement classes which have no explicit CDOModelElement class
associated. Since packages are always allocated/transferred/stored/loaded
as a unit, the meta IDs of the EModelElements always form an unbroken
range, the CDOIDMetaRange of that package. It's more an optimization of
network transfer and storage code/space. The CDO client will use this
range to associate the real EModelElements with their persistent meta IDs
so that they can be referenced from instances. This is mostly needed when
modeled classes have references to model elements.

> One other thing I noticed in EMFUtil is that you use a direct XMIResource to
do the translation. I
> am not sure if this works if you have multiple epackages which refer to
eachother. Afaik to get this
> working correctly a resourceset should always be used so that the lookups
for other packages are
> done through the epackageregistry.
You might be right. I'll clarify this when I have access to my code again
;-) Thx!

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: Hibernate-CDO [message #111844 is a reply to message #111839]

Wed, 06 February 2008 10:28

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Eike,
Reaction below.

gr. Martin

Eike Stepper wrote:
> Martin Taal wrote:
>> Hi Eike,
>> I can see that there is code to initialize a cdopackage from an ecore
> string. I remember you said
>> that the cdo-server did not depend on emf. This means that the
> initialization of the cdopackage from
>> an ecore string is always used on the client, right?
> No, I fear that not. There might be a ctor/setter to fill the ecore
> String field of CDOPackageImpl. But there are no means on the server to
> to turn this String into a CDOPackage instance. We could easily turn the
> String into an EPackage instance in the HibernateStore plugin. But do we
> really need to turn that one into a CDOPackageImpl?
MT>> No it was just a question, I saw the code in the CDOSessionPackageManagerImpl.resolve and it
initializes a cdoPackage from an EPackage. The current approach (only using the ecore string to
initialize teneo) should work fine.

>
>> Regarding persisting the cdopackageimpl through hibernate. Hibernate
> requires a class to have a
>> no-arg constructor. In addition it is easier if the members are all
> settable/gettable through
>> accessors. I have attached a patch to the bugzilla for this.
> I saw it and applied/committed the patch already.
>
>> Some other smaller questions:
>> - Would it be possible to set the CDOPackageManager in the CDOPackage
>> in the CDOPackageManager.addPackage method instead of in the
>> constructor? Then the
> persistence layer (when
>> reading the cdopackage from the db) does not need to do that.
> Isn't there a separate setPackageManage() method anyway? I recall that
> it's needed during a commit operation where there is temporarily used a
> TransactionalPackageManager which is later replaced by the usual
> SessionPackageManager.
MT>> Okay no problem, it was more a theoretical question

>
>> - What is the purpose of CDOClassProxy?
> IIRC it is a wrapper for a CDOClass and/or a CDOClassRef. There are
> situations where there is for a certain period only a CDOClassRef
> available (e.g. SuperType refs while receiving/storing a CDOPackage) and
> later the CDOClassRef can be resolved to a CDOClass. CDOClassProxy makes
> it a bit easier for the rest of the framework to handle these 2 distinct
> cases.
MT>> Okay, in the patch I sent you I added a get/set methods to directly set a CDOClass (which is
internally wrapped in a CDOClassProxy) because it makes the hibernate mapping easier.

>
>> - What is the purpose of the CDOIDMetaRange?
> Each EModelElement has an own CDOID, a meta ID. There are some
> EModelElement classes which have no explicit CDOModelElement class
> associated. Since packages are always
> allocated/transferred/stored/loaded as a unit, the meta IDs of the
> EModelElements always form an unbroken range, the CDOIDMetaRange of that
> package. It's more an optimization of network transfer and storage
> code/space. The CDO client will use this range to associate the real
> EModelElements with their persistent meta IDs so that they can be
> referenced from instances. This is mostly needed when modeled classes
> have references to model elements.
MT>> Okay, then I know that I can persist these assuming that they are longs.

>
>> One other thing I noticed in EMFUtil is that you use a direct
>> XMIResource to
> do the translation. I
>> am not sure if this works if you have multiple epackages which refer to
> eachother. Afaik to get this
>> working correctly a resourceset should always be used so that the lookups
> for other packages are
>> done through the epackageregistry.
> You might be right. I'll clarify this when I have access to my code
> again ;-) Thx!
MT>> I am not 100% sure, there are some posts about this on the newsgroup but I could not find them
anymore....

>
>
>

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org

Report message to a moderator

Re: Hibernate-CDO [message #111849 is a reply to message #111844]

Wed, 06 February 2008 13:09

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Martin Taal wrote:

> Hi Eike,
> Reaction below.

> gr. Martin

> Eike Stepper wrote:
>> Martin Taal wrote:
>>> Hi Eike,
>>> I can see that there is code to initialize a cdopackage from an ecore
>> string. I remember you said
>>> that the cdo-server did not depend on emf. This means that the
>> initialization of the cdopackage from
>>> an ecore string is always used on the client, right?
>> No, I fear that not. There might be a ctor/setter to fill the ecore
>> String field of CDOPackageImpl. But there are no means on the server to
>> to turn this String into a CDOPackage instance. We could easily turn the
>> String into an EPackage instance in the HibernateStore plugin. But do we
>> really need to turn that one into a CDOPackageImpl?
> MT>> No it was just a question, I saw the code in the
CDOSessionPackageManagerImpl.resolve and it
> initializes a cdoPackage from an EPackage. The current approach (only using
the ecore string to
> initialize teneo) should work fine.
Oh, you're right. I misread your question. Correct: the ecore-string -->
CDOPackageImpl thing exists only on the CDO client ;-)

>>> Regarding persisting the cdopackageimpl through hibernate. Hibernate
>> requires a class to have a
>>> no-arg constructor. In addition it is easier if the members are all
>> settable/gettable through
>>> accessors. I have attached a patch to the bugzilla for this.
>> I saw it and applied/committed the patch already.
>>
>>> Some other smaller questions:
>>> - Would it be possible to set the CDOPackageManager in the CDOPackage
>>> in the CDOPackageManager.addPackage method instead of in the
>>> constructor? Then the
>> persistence layer (when
>>> reading the cdopackage from the db) does not need to do that.
>> Isn't there a separate setPackageManage() method anyway? I recall that
>> it's needed during a commit operation where there is temporarily used a
>> TransactionalPackageManager which is later replaced by the usual
>> SessionPackageManager.
> MT>> Okay no problem, it was more a theoretical question

>>
>>> - What is the purpose of CDOClassProxy?
>> IIRC it is a wrapper for a CDOClass and/or a CDOClassRef. There are
>> situations where there is for a certain period only a CDOClassRef
>> available (e.g. SuperType refs while receiving/storing a CDOPackage) and
>> later the CDOClassRef can be resolved to a CDOClass. CDOClassProxy makes
>> it a bit easier for the rest of the framework to handle these 2 distinct
>> cases.
> MT>> Okay, in the patch I sent you I added a get/set methods to directly set
a CDOClass (which is
> internally wrapped in a CDOClassProxy) because it makes the hibernate
mapping easier.

>>
>>> - What is the purpose of the CDOIDMetaRange?
>> Each EModelElement has an own CDOID, a meta ID. There are some
>> EModelElement classes which have no explicit CDOModelElement class
>> associated. Since packages are always
>> allocated/transferred/stored/loaded as a unit, the meta IDs of the
>> EModelElements always form an unbroken range, the CDOIDMetaRange of that
>> package. It's more an optimization of network transfer and storage
>> code/space. The CDO client will use this range to associate the real
>> EModelElements with their persistent meta IDs so that they can be
>> referenced from instances. This is mostly needed when modeled classes
>> have references to model elements.
> MT>> Okay, then I know that I can persist these assuming that they are longs.
More exactly, I recently changed the internal structure/format or the
CDOIDMetaRange to long lowerBound and int size because that made certain
calculations a bit easier.

Cheers
/Eike

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator