Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » CDO-Hibernate-Teneo
| CDO-Hibernate-Teneo [message #111737] |
Mon, 04 February 2008 10:13  |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
I have started to integration with the teneo mapping generator. For this I have created an interface
HibernateMappingGenerator and an implementation (TeneoHibernateMappingProvider) in a separate plugin.
I have changed the structure of the hibernate store, mainly that the handling of cdopackages is done
using a separate sessionfactory.
The initialzation is now a two-step procedure: 1) initialize the package sessionfactory/store, 2)
read the cdopackages from the database and generate the mapping.
I moved the code for handling (reading/writing) cdopackages to a separate class. This made the
hibernatestore code and initialization a bit cleaner.
I started to work on the unsupportedexceptions. My first one is related to the method:
HibernateStoreWriter.primeNewObject. This method gets a class and returns a new cdoid object. Is
this method for new objects which need to be persisted?
I also noticed that the first object which is persisted is a resource object. You mentioned before
that resources are persisted. What is the (database) model for a resource? In your opinion, should
this be added to a static cdo hibernate mapping (meta.hbm.xml)?
Hibernate works best if each type (eclass) also has a version feature for handling optimistic
locking. It also uses the version property to detect if an object is new or not. In your testmodel
there is no version feature and not all types have a feature which can be used for the id. Do you
agree that I create a separate testmodel which contains this info together with some teneo
annotations? It can be a copy of model1.
Btw, I think you detect that an object is new by looking at the cdoid, correct? Maybe we can use
that in hibernate to detect 'new-ness' instead of the version feature.
--
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
|
|
| |
| Re: CDO-Hibernate-Teneo [message #111753 is a reply to message #111748] |
Mon, 04 February 2008 20:07  |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Martin,
I've attached a patch to bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=217117
Please cc yourself then we can use it to discuss.
Cheers
/Eike
Eike Stepper schrieb:
> Hi Martin,
>
> As I mentioned I£m a bit limited here with my customer, including the
> swiss keyboard ;-)
> I just read your comments and would like to warn you: I£ve got a lot of
> API changes in my local workspace which I can£t commit before they£re
> tested. I can send you a patch so that you can preview. It all depends a
> bit on how easy I£ll get net-access in the hotel later on...
>
> Cheers
> /Eike
>
>
>
|
|
|
| Re: CDO-Hibernate-Teneo [message #111758 is a reply to message #111737] |
Mon, 04 February 2008 20:18 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Martin Taal schrieb:
> Hi Eike,
> I have started to integration with the teneo mapping generator. For this
> I have created an interface HibernateMappingGenerator and an
> implementation (TeneoHibernateMappingProvider) in a separate plugin.
> I have changed the structure of the hibernate store, mainly that the
> handling of cdopackages is done using a separate sessionfactory.
> The initialzation is now a two-step procedure: 1) initialize the package
> sessionfactory/store, 2) read the cdopackages from the database and
> generate the mapping.
> I moved the code for handling (reading/writing) cdopackages to a
> separate class. This made the hibernatestore code and initialization a
> bit cleaner.
This seems to be more like a static refactoring without influence on the functionality, right?
>
> I started to work on the unsupportedexceptions. My first one is related
> to the method:
> HibernateStoreWriter.primeNewObject. This method gets a class and
> returns a new cdoid object. Is this method for new objects which need to
> be persisted?
This method doesn't exist anymore with the Patch v1.
> I also noticed that the first object which is persisted is a resource
> object. You mentioned before that resources are persisted. What is the
> (database) model for a resource? In your opinion, should this be added
> to a static cdo hibernate mapping (meta.hbm.xml)?
With CDO a Resource is really an ordinary persistent object much like any other EObject. I think there's no need to add it to the static meta model mapping. At least there was no need for the DBStore. I recall that the CDOResource class has only 2 non-transient features: path and contents. These should be mapped as normal for EObjects.
>
> Hibernate works best if each type (eclass) also has a version feature
> for handling optimistic locking. It also uses the version property to
> detect if an object is new or not. In your testmodel there is no version
> feature and not all types have a feature which can be used for the id.
> Do you agree that I create a separate testmodel which contains this info
> together with some teneo annotations? It can be a copy of model1.
The version is, much like the CDOID, an internal "feature" of each CDOObject:
public interface CDOObject extends EObject
{
public CDOClass cdoClass();
public CDOID cdoID();
public CDOState cdoState();
public CDOView cdoView();
public CDOResource cdoResource();
public CDORevision cdoRevision();
}
Of course you can create a separate test model if you think this is necessary ;-)
>
> Btw, I think you detect that an object is new by looking at the cdoid,
> correct? Maybe we can use that in hibernate to detect 'new-ness' instead
> of the version feature.
Hmm, I think you're right. Currently I use something like revision.getID().isTemporary() which indicates if the object has a temporary id because it was newly created in a client side transaction. revision.getVersion() == 1 would have the same effect.
Cheers
/EIke
|
|
|
| Re: CDO-Hibernate-Teneo [message #111780 is a reply to message #111758] |
Mon, 04 February 2008 22:03 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
See below.
gr. Martin
Eike Stepper wrote:
> Martin Taal schrieb:
>> Hi Eike,
>> I have started to integration with the teneo mapping generator. For
>> this I have created an interface HibernateMappingGenerator and an
>> implementation (TeneoHibernateMappingProvider) in a separate plugin.
>> I have changed the structure of the hibernate store, mainly that the
>> handling of cdopackages is done using a separate sessionfactory.
>> The initialzation is now a two-step procedure: 1) initialize the
>> package sessionfactory/store, 2) read the cdopackages from the
>> database and generate the mapping.
>> I moved the code for handling (reading/writing) cdopackages to a
>> separate class. This made the hibernatestore code and initialization a
>> bit cleaner.
> This seems to be more like a static refactoring without influence on the
> functionality, right?
MT>> I did not change the current functionality but added re-initialization of the store when the
epackages change.
>
>
>>
>> I started to work on the unsupportedexceptions. My first one is
>> related to the method:
>> HibernateStoreWriter.primeNewObject. This method gets a class and
>> returns a new cdoid object. Is this method for new objects which need
>> to be persisted?
> This method doesn't exist anymore with the Patch v1.
MT>> that's easy :-)
>
>
>> I also noticed that the first object which is persisted is a resource
>> object. You mentioned before that resources are persisted. What is the
>> (database) model for a resource? In your opinion, should this be added
>> to a static cdo hibernate mapping (meta.hbm.xml)?
> With CDO a Resource is really an ordinary persistent object much like
> any other EObject. I think there's no need to add it to the static meta
> model mapping. At least there was no need for the DBStore. I recall that
> the CDOResource class has only 2 non-transient features: path and
> contents. These should be mapped as normal for EObjects.
MT>> contents can contain any type of eobject from the model, right? If the resource is also
persisted then I can add it to the generated mapping. I need to think about how to map the contents
feature (assuming that any type of eobject can be in the root of the resource).
>
>
>>
>> Hibernate works best if each type (eclass) also has a version feature
>> for handling optimistic locking. It also uses the version property to
>> detect if an object is new or not. In your testmodel there is no
>> version feature and not all types have a feature which can be used for
>> the id. Do you agree that I create a separate testmodel which contains
>> this info together with some teneo annotations? It can be a copy of
>> model1.
> The version is, much like the CDOID, an internal "feature" of each
> CDOObject:
>
> public interface CDOObject extends EObject
> {
> public CDOClass cdoClass();
> public CDOID cdoID();
> public CDOState cdoState();
> public CDOView cdoView();
> public CDOResource cdoResource();
> public CDORevision cdoRevision();
> }
>
> Of course you can create a separate test model if you think this is
> necessary ;-)
MT>> It is better if we can use the current native version support of cdo. Below I see you can do
cdoRevision.getVersion() to get the version number.
>
>
>>
>> Btw, I think you detect that an object is new by looking at the cdoid,
>> correct? Maybe we can use that in hibernate to detect 'new-ness'
>> instead of the version feature.
>
> Hmm, I think you're right. Currently I use something like
> revision.getID().isTemporary() which indicates if the object has a
> temporary id because it was newly created in a client side transaction.
> revision.getVersion() == 1 would have the same effect.
MT>> Okay
>
> Cheers
> /EIke
--
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
|
|
|
| Re: CDO-Hibernate-Teneo [message #111786 is a reply to message #111753] |
Mon, 04 February 2008 22:05 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
The attachment in the bugzilla was only 69 bytes it seemed. Is there another file I should download?
I have added myself as cc.
Okay, I will take care of the hbm for the cdopackage. Did you check in your last version?
Btw, I did the part which reads the ecore str. from the cdopackage and translates it into an ecore
model.
gr. Martin
Eike Stepper wrote:
> Hi Martin,
>
> I've attached a patch to bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=217117
> Please cc yourself then we can use it to discuss.
>
> Cheers
> /Eike
>
>
> Eike Stepper schrieb:
>> Hi Martin,
>>
>> As I mentioned I£m a bit limited here with my customer, including the
>> swiss keyboard ;-)
>> I just read your comments and would like to warn you: I£ve got a lot
>> of API changes in my local workspace which I can£t commit before
>> they£re tested. I can send you a patch so that you can preview. It all
>> depends a bit on how easy I£ll get net-access in the hotel later on...
>>
>> Cheers
>> /Eike
>>
>>
>>
--
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
|
|
|
| Re: CDO-Hibernate-Teneo [message #111792 is a reply to message #111786] |
Tue, 05 February 2008 06:42 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Martin Taal schrieb:
> Hi Eike,
> The attachment in the bugzilla was only 69 bytes it seemed. Is there
> another file I should download?
Grr. somehow the create patch (Mylyn ChangeSet) didn't work ;-(
I'll try it again...
> I have added myself as cc.
>
> Okay, I will take care of the hbm for the cdopackage. Did you check in
> your last version?
No, my DBStore is currently broken due to the changes. Hopefully I can fix, test and commit that this evening. This is why I tried to post a patch which you can use to get my latest local state.
> Btw, I did the part which reads the ecore str. from the cdopackage and
> translates it into an ecore model.
Ah, great ;-)
I'm thinking about creating a sibling folder to org.eclipse.emf.cdo/plugins/ in CVS, so that I can nominate you as a committer for that folder. Then you'd be able to add new plugins as well.
Cheers
/Eike
>
> gr. Martin
>
> Eike Stepper wrote:
>> Hi Martin,
>>
>> I've attached a patch to bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=217117
>> Please cc yourself then we can use it to discuss.
>>
>> Cheers
>> /Eike
>>
>>
>> Eike Stepper schrieb:
>>> Hi Martin,
>>>
>>> As I mentioned I£m a bit limited here with my customer, including the
>>> swiss keyboard ;-)
>>> I just read your comments and would like to warn you: I£ve got a lot
>>> of API changes in my local workspace which I can£t commit before
>>> they£re tested. I can send you a patch so that you can preview. It
>>> all depends a bit on how easy I£ll get net-access in the hotel later
>>> on...
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>
>
|
|
|
| Re: CDO-Hibernate-Teneo [message #111795 is a reply to message #111780] |
Tue, 05 February 2008 06:54 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Martin Taal schrieb:
> Hi Eike,
> See below.
>
> gr. Martin
>
> Eike Stepper wrote:
>> Martin Taal schrieb:
>>> Hi Eike,
>>> I have started to integration with the teneo mapping generator. For
>>> this I have created an interface HibernateMappingGenerator and an
>>> implementation (TeneoHibernateMappingProvider) in a separate plugin.
>>> I have changed the structure of the hibernate store, mainly that the
>>> handling of cdopackages is done using a separate sessionfactory.
>>> The initialzation is now a two-step procedure: 1) initialize the
>>> package sessionfactory/store, 2) read the cdopackages from the
>>> database and generate the mapping.
>>> I moved the code for handling (reading/writing) cdopackages to a
>>> separate class. This made the hibernatestore code and initialization
>>> a bit cleaner.
>> This seems to be more like a static refactoring without influence on
>> the functionality, right?
> MT>> I did not change the current functionality but added
> re-initialization of the store when the epackages change.
Ok, that seems fine. Can you add a patch to https://bugs.eclipse.org/bugs/show_bug.cgi?id=217117 for your changes after you merged in my Patch v2?
>>> I also noticed that the first object which is persisted is a resource
>>> object. You mentioned before that resources are persisted. What is
>>> the (database) model for a resource? In your opinion, should this be
>>> added to a static cdo hibernate mapping (meta.hbm.xml)?
>> With CDO a Resource is really an ordinary persistent object much like
>> any other EObject. I think there's no need to add it to the static
>> meta model mapping. At least there was no need for the DBStore. I
>> recall that the CDOResource class has only 2 non-transient features:
>> path and contents. These should be mapped as normal for EObjects.
> MT>> contents can contain any type of eobject from the model, right? If
> the resource is also persisted then I can add it to the generated
> mapping. I need to think about how to map the contents feature (assuming
> that any type of eobject can be in the root of the resource).
Do you mean "add it to the manually created mapping"?
I think either approach is ok. I leave it up to you.
The problem with EObject as target type for references could potentially occur at other model places as well, right? An internal flat technical key is practical for these cases ;-)
>>> Hibernate works best if each type (eclass) also has a version feature
>>> for handling optimistic locking. It also uses the version property to
>>> detect if an object is new or not. In your testmodel there is no
>>> version feature and not all types have a feature which can be used
>>> for the id. Do you agree that I create a separate testmodel which
>>> contains this info together with some teneo annotations? It can be a
>>> copy of model1.
>> The version is, much like the CDOID, an internal "feature" of each
>> CDOObject:
>>
>> public interface CDOObject extends EObject
>> {
>> public CDOClass cdoClass();
>> public CDOID cdoID();
>> public CDOState cdoState();
>> public CDOView cdoView();
>> public CDOResource cdoResource();
>> public CDORevision cdoRevision();
>> }
>>
>> Of course you can create a separate test model if you think this is
>> necessary ;-)
> MT>> It is better if we can use the current native version support of
> cdo. Below I see you can do cdoRevision.getVersion() to get the version
> number.
Right ;-)
Cheers
/Eike
>>> Btw, I think you detect that an object is new by looking at the
>>> cdoid, correct? Maybe we can use that in hibernate to detect
>>> 'new-ness' instead of the version feature.
>>
>> Hmm, I think you're right. Currently I use something like
>> revision.getID().isTemporary() which indicates if the object has a
>> temporary id because it was newly created in a client side
>> transaction. revision.getVersion() == 1 would have the same effect.
> MT>> Okay
>
>>
>> Cheers
>> /EIke
>
>
|
|
|
| Re: CDO-Hibernate-Teneo [message #111801 is a reply to message #111795] |
Tue, 05 February 2008 12:32 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Yes I will add a patch, this will probably be tomorrow as it really needs to do something (persist
objects) before I want to send something.
With internal flat key, you mean something like a generic reference which can be stored in a string
field. The reference is then for example classname followed by id or something. At least that is
what I was thinking of.
gr. Martin
Eike Stepper wrote:
> Martin Taal schrieb:
>> Hi Eike,
>> See below.
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> Martin Taal schrieb:
>>>> Hi Eike,
>>>> I have started to integration with the teneo mapping generator. For
>>>> this I have created an interface HibernateMappingGenerator and an
>>>> implementation (TeneoHibernateMappingProvider) in a separate plugin.
>>>> I have changed the structure of the hibernate store, mainly that the
>>>> handling of cdopackages is done using a separate sessionfactory.
>>>> The initialzation is now a two-step procedure: 1) initialize the
>>>> package sessionfactory/store, 2) read the cdopackages from the
>>>> database and generate the mapping.
>>>> I moved the code for handling (reading/writing) cdopackages to a
>>>> separate class. This made the hibernatestore code and initialization
>>>> a bit cleaner.
>>> This seems to be more like a static refactoring without influence on
>>> the functionality, right?
>> MT>> I did not change the current functionality but added
>> re-initialization of the store when the epackages change.
> Ok, that seems fine. Can you add a patch to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=217117 for your changes
> after you merged in my Patch v2?
>
>
>>>> I also noticed that the first object which is persisted is a
>>>> resource object. You mentioned before that resources are persisted.
>>>> What is the (database) model for a resource? In your opinion, should
>>>> this be added to a static cdo hibernate mapping (meta.hbm.xml)?
>>> With CDO a Resource is really an ordinary persistent object much like
>>> any other EObject. I think there's no need to add it to the static
>>> meta model mapping. At least there was no need for the DBStore. I
>>> recall that the CDOResource class has only 2 non-transient features:
>>> path and contents. These should be mapped as normal for EObjects.
>> MT>> contents can contain any type of eobject from the model, right?
>> If the resource is also persisted then I can add it to the generated
>> mapping. I need to think about how to map the contents feature
>> (assuming that any type of eobject can be in the root of the resource).
> Do you mean "add it to the manually created mapping"?
> I think either approach is ok. I leave it up to you.
> The problem with EObject as target type for references could potentially
> occur at other model places as well, right? An internal flat technical
> key is practical for these cases ;-)
>
>
>>>> Hibernate works best if each type (eclass) also has a version
>>>> feature for handling optimistic locking. It also uses the version
>>>> property to detect if an object is new or not. In your testmodel
>>>> there is no version feature and not all types have a feature which
>>>> can be used for the id. Do you agree that I create a separate
>>>> testmodel which contains this info together with some teneo
>>>> annotations? It can be a copy of model1.
>>> The version is, much like the CDOID, an internal "feature" of each
>>> CDOObject:
>>>
>>> public interface CDOObject extends EObject
>>> {
>>> public CDOClass cdoClass();
>>> public CDOID cdoID();
>>> public CDOState cdoState();
>>> public CDOView cdoView();
>>> public CDOResource cdoResource();
>>> public CDORevision cdoRevision();
>>> }
>>>
>>> Of course you can create a separate test model if you think this is
>>> necessary ;-)
>> MT>> It is better if we can use the current native version support of
>> cdo. Below I see you can do cdoRevision.getVersion() to get the
>> version number.
> Right ;-)
>
>
> Cheers
> /Eike
>
>
>>>> Btw, I think you detect that an object is new by looking at the
>>>> cdoid, correct? Maybe we can use that in hibernate to detect
>>>> 'new-ness' instead of the version feature.
>>>
>>> Hmm, I think you're right. Currently I use something like
>>> revision.getID().isTemporary() which indicates if the object has a
>>> temporary id because it was newly created in a client side
>>> transaction. revision.getVersion() == 1 would have the same effect.
>> MT>> Okay
>>
>>>
>>> Cheers
>>> /EIke
>>
>>
--
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
|
|
| | |
| Re: CDO-Hibernate-Teneo [message #615392 is a reply to message #111737] |
Mon, 04 February 2008 20:18 |
|
Martin Taal schrieb:
> Hi Eike,
> I have started to integration with the teneo mapping generator. For this
> I have created an interface HibernateMappingGenerator and an
> implementation (TeneoHibernateMappingProvider) in a separate plugin.
> I have changed the structure of the hibernate store, mainly that the
> handling of cdopackages is done using a separate sessionfactory.
> The initialzation is now a two-step procedure: 1) initialize the package
> sessionfactory/store, 2) read the cdopackages from the database and
> generate the mapping.
> I moved the code for handling (reading/writing) cdopackages to a
> separate class. This made the hibernatestore code and initialization a
> bit cleaner.
This seems to be more like a static refactoring without influence on the functionality, right?
>
> I started to work on the unsupportedexceptions. My first one is related
> to the method:
> HibernateStoreWriter.primeNewObject. This method gets a class and
> returns a new cdoid object. Is this method for new objects which need to
> be persisted?
This method doesn't exist anymore with the Patch v1.
> I also noticed that the first object which is persisted is a resource
> object. You mentioned before that resources are persisted. What is the
> (database) model for a resource? In your opinion, should this be added
> to a static cdo hibernate mapping (meta.hbm.xml)?
With CDO a Resource is really an ordinary persistent object much like any other EObject. I think there's no need to add it to the static meta model mapping. At least there was no need for the DBStore. I recall that the CDOResource class has only 2 non-transient features: path and contents. These should be mapped as normal for EObjects.
>
> Hibernate works best if each type (eclass) also has a version feature
> for handling optimistic locking. It also uses the version property to
> detect if an object is new or not. In your testmodel there is no version
> feature and not all types have a feature which can be used for the id.
> Do you agree that I create a separate testmodel which contains this info
> together with some teneo annotations? It can be a copy of model1.
The version is, much like the CDOID, an internal "feature" of each CDOObject:
public interface CDOObject extends EObject
{
public CDOClass cdoClass();
public CDOID cdoID();
public CDOState cdoState();
public CDOView cdoView();
public CDOResource cdoResource();
public CDORevision cdoRevision();
}
Of course you can create a separate test model if you think this is necessary ;-)
>
> Btw, I think you detect that an object is new by looking at the cdoid,
> correct? Maybe we can use that in hibernate to detect 'new-ness' instead
> of the version feature.
Hmm, I think you're right. Currently I use something like revision.getID().isTemporary() which indicates if the object has a temporary id because it was newly created in a client side transaction. revision.getVersion() == 1 would have the same effect.
Cheers
/EIke
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: CDO-Hibernate-Teneo [message #615396 is a reply to message #111758] |
Mon, 04 February 2008 22:03 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
See below.
gr. Martin
Eike Stepper wrote:
> Martin Taal schrieb:
>> Hi Eike,
>> I have started to integration with the teneo mapping generator. For
>> this I have created an interface HibernateMappingGenerator and an
>> implementation (TeneoHibernateMappingProvider) in a separate plugin.
>> I have changed the structure of the hibernate store, mainly that the
>> handling of cdopackages is done using a separate sessionfactory.
>> The initialzation is now a two-step procedure: 1) initialize the
>> package sessionfactory/store, 2) read the cdopackages from the
>> database and generate the mapping.
>> I moved the code for handling (reading/writing) cdopackages to a
>> separate class. This made the hibernatestore code and initialization a
>> bit cleaner.
> This seems to be more like a static refactoring without influence on the
> functionality, right?
MT>> I did not change the current functionality but added re-initialization of the store when the
epackages change.
>
>
>>
>> I started to work on the unsupportedexceptions. My first one is
>> related to the method:
>> HibernateStoreWriter.primeNewObject. This method gets a class and
>> returns a new cdoid object. Is this method for new objects which need
>> to be persisted?
> This method doesn't exist anymore with the Patch v1.
MT>> that's easy :-)
>
>
>> I also noticed that the first object which is persisted is a resource
>> object. You mentioned before that resources are persisted. What is the
>> (database) model for a resource? In your opinion, should this be added
>> to a static cdo hibernate mapping (meta.hbm.xml)?
> With CDO a Resource is really an ordinary persistent object much like
> any other EObject. I think there's no need to add it to the static meta
> model mapping. At least there was no need for the DBStore. I recall that
> the CDOResource class has only 2 non-transient features: path and
> contents. These should be mapped as normal for EObjects.
MT>> contents can contain any type of eobject from the model, right? If the resource is also
persisted then I can add it to the generated mapping. I need to think about how to map the contents
feature (assuming that any type of eobject can be in the root of the resource).
>
>
>>
>> Hibernate works best if each type (eclass) also has a version feature
>> for handling optimistic locking. It also uses the version property to
>> detect if an object is new or not. In your testmodel there is no
>> version feature and not all types have a feature which can be used for
>> the id. Do you agree that I create a separate testmodel which contains
>> this info together with some teneo annotations? It can be a copy of
>> model1.
> The version is, much like the CDOID, an internal "feature" of each
> CDOObject:
>
> public interface CDOObject extends EObject
> {
> public CDOClass cdoClass();
> public CDOID cdoID();
> public CDOState cdoState();
> public CDOView cdoView();
> public CDOResource cdoResource();
> public CDORevision cdoRevision();
> }
>
> Of course you can create a separate test model if you think this is
> necessary ;-)
MT>> It is better if we can use the current native version support of cdo. Below I see you can do
cdoRevision.getVersion() to get the version number.
>
>
>>
>> Btw, I think you detect that an object is new by looking at the cdoid,
>> correct? Maybe we can use that in hibernate to detect 'new-ness'
>> instead of the version feature.
>
> Hmm, I think you're right. Currently I use something like
> revision.getID().isTemporary() which indicates if the object has a
> temporary id because it was newly created in a client side transaction.
> revision.getVersion() == 1 would have the same effect.
MT>> Okay
>
> Cheers
> /EIke
--
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
|
|
|
| Re: CDO-Hibernate-Teneo [message #615397 is a reply to message #111753] |
Mon, 04 February 2008 22:05 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
The attachment in the bugzilla was only 69 bytes it seemed. Is there another file I should download?
I have added myself as cc.
Okay, I will take care of the hbm for the cdopackage. Did you check in your last version?
Btw, I did the part which reads the ecore str. from the cdopackage and translates it into an ecore
model.
gr. Martin
Eike Stepper wrote:
> Hi Martin,
>
> I've attached a patch to bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=217117
> Please cc yourself then we can use it to discuss.
>
> Cheers
> /Eike
>
>
> Eike Stepper schrieb:
>> Hi Martin,
>>
>> As I mentioned I£m a bit limited here with my customer, including the
>> swiss keyboard ;-)
>> I just read your comments and would like to warn you: I£ve got a lot
>> of API changes in my local workspace which I can£t commit before
>> they£re tested. I can send you a patch so that you can preview. It all
>> depends a bit on how easy I£ll get net-access in the hotel later on...
>>
>> Cheers
>> /Eike
>>
>>
>>
--
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
|
|
|
| Re: CDO-Hibernate-Teneo [message #615398 is a reply to message #111786] |
Tue, 05 February 2008 06:42 |
|
Martin Taal schrieb:
> Hi Eike,
> The attachment in the bugzilla was only 69 bytes it seemed. Is there
> another file I should download?
Grr. somehow the create patch (Mylyn ChangeSet) didn't work ;-(
I'll try it again...
> I have added myself as cc.
>
> Okay, I will take care of the hbm for the cdopackage. Did you check in
> your last version?
No, my DBStore is currently broken due to the changes. Hopefully I can fix, test and commit that this evening. This is why I tried to post a patch which you can use to get my latest local state.
> Btw, I did the part which reads the ecore str. from the cdopackage and
> translates it into an ecore model.
Ah, great ;-)
I'm thinking about creating a sibling folder to org.eclipse.emf.cdo/plugins/ in CVS, so that I can nominate you as a committer for that folder. Then you'd be able to add new plugins as well.
Cheers
/Eike
>
> gr. Martin
>
> Eike Stepper wrote:
>> Hi Martin,
>>
>> I've attached a patch to bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=217117
>> Please cc yourself then we can use it to discuss.
>>
>> Cheers
>> /Eike
>>
>>
>> Eike Stepper schrieb:
>>> Hi Martin,
>>>
>>> As I mentioned I£m a bit limited here with my customer, including the
>>> swiss keyboard ;-)
>>> I just read your comments and would like to warn you: I£ve got a lot
>>> of API changes in my local workspace which I can£t commit before
>>> they£re tested. I can send you a patch so that you can preview. It
>>> all depends a bit on how easy I£ll get net-access in the hotel later
>>> on...
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: CDO-Hibernate-Teneo [message #615399 is a reply to message #111780] |
Tue, 05 February 2008 06:54 |
|
Martin Taal schrieb:
> Hi Eike,
> See below.
>
> gr. Martin
>
> Eike Stepper wrote:
>> Martin Taal schrieb:
>>> Hi Eike,
>>> I have started to integration with the teneo mapping generator. For
>>> this I have created an interface HibernateMappingGenerator and an
>>> implementation (TeneoHibernateMappingProvider) in a separate plugin.
>>> I have changed the structure of the hibernate store, mainly that the
>>> handling of cdopackages is done using a separate sessionfactory.
>>> The initialzation is now a two-step procedure: 1) initialize the
>>> package sessionfactory/store, 2) read the cdopackages from the
>>> database and generate the mapping.
>>> I moved the code for handling (reading/writing) cdopackages to a
>>> separate class. This made the hibernatestore code and initialization
>>> a bit cleaner.
>> This seems to be more like a static refactoring without influence on
>> the functionality, right?
> MT>> I did not change the current functionality but added
> re-initialization of the store when the epackages change.
Ok, that seems fine. Can you add a patch to https://bugs.eclipse.org/bugs/show_bug.cgi?id=217117 for your changes after you merged in my Patch v2?
>>> I also noticed that the first object which is persisted is a resource
>>> object. You mentioned before that resources are persisted. What is
>>> the (database) model for a resource? In your opinion, should this be
>>> added to a static cdo hibernate mapping (meta.hbm.xml)?
>> With CDO a Resource is really an ordinary persistent object much like
>> any other EObject. I think there's no need to add it to the static
>> meta model mapping. At least there was no need for the DBStore. I
>> recall that the CDOResource class has only 2 non-transient features:
>> path and contents. These should be mapped as normal for EObjects.
> MT>> contents can contain any type of eobject from the model, right? If
> the resource is also persisted then I can add it to the generated
> mapping. I need to think about how to map the contents feature (assuming
> that any type of eobject can be in the root of the resource).
Do you mean "add it to the manually created mapping"?
I think either approach is ok. I leave it up to you.
The problem with EObject as target type for references could potentially occur at other model places as well, right? An internal flat technical key is practical for these cases ;-)
>>> Hibernate works best if each type (eclass) also has a version feature
>>> for handling optimistic locking. It also uses the version property to
>>> detect if an object is new or not. In your testmodel there is no
>>> version feature and not all types have a feature which can be used
>>> for the id. Do you agree that I create a separate testmodel which
>>> contains this info together with some teneo annotations? It can be a
>>> copy of model1.
>> The version is, much like the CDOID, an internal "feature" of each
>> CDOObject:
>>
>> public interface CDOObject extends EObject
>> {
>> public CDOClass cdoClass();
>> public CDOID cdoID();
>> public CDOState cdoState();
>> public CDOView cdoView();
>> public CDOResource cdoResource();
>> public CDORevision cdoRevision();
>> }
>>
>> Of course you can create a separate test model if you think this is
>> necessary ;-)
> MT>> It is better if we can use the current native version support of
> cdo. Below I see you can do cdoRevision.getVersion() to get the version
> number.
Right ;-)
Cheers
/Eike
>>> Btw, I think you detect that an object is new by looking at the
>>> cdoid, correct? Maybe we can use that in hibernate to detect
>>> 'new-ness' instead of the version feature.
>>
>> Hmm, I think you're right. Currently I use something like
>> revision.getID().isTemporary() which indicates if the object has a
>> temporary id because it was newly created in a client side
>> transaction. revision.getVersion() == 1 would have the same effect.
> MT>> Okay
>
>>
>> Cheers
>> /EIke
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: CDO-Hibernate-Teneo [message #615400 is a reply to message #111795] |
Tue, 05 February 2008 12:32 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Yes I will add a patch, this will probably be tomorrow as it really needs to do something (persist
objects) before I want to send something.
With internal flat key, you mean something like a generic reference which can be stored in a string
field. The reference is then for example classname followed by id or something. At least that is
what I was thinking of.
gr. Martin
Eike Stepper wrote:
> Martin Taal schrieb:
>> Hi Eike,
>> See below.
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> Martin Taal schrieb:
>>>> Hi Eike,
>>>> I have started to integration with the teneo mapping generator. For
>>>> this I have created an interface HibernateMappingGenerator and an
>>>> implementation (TeneoHibernateMappingProvider) in a separate plugin.
>>>> I have changed the structure of the hibernate store, mainly that the
>>>> handling of cdopackages is done using a separate sessionfactory.
>>>> The initialzation is now a two-step procedure: 1) initialize the
>>>> package sessionfactory/store, 2) read the cdopackages from the
>>>> database and generate the mapping.
>>>> I moved the code for handling (reading/writing) cdopackages to a
>>>> separate class. This made the hibernatestore code and initialization
>>>> a bit cleaner.
>>> This seems to be more like a static refactoring without influence on
>>> the functionality, right?
>> MT>> I did not change the current functionality but added
>> re-initialization of the store when the epackages change.
> Ok, that seems fine. Can you add a patch to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=217117 for your changes
> after you merged in my Patch v2?
>
>
>>>> I also noticed that the first object which is persisted is a
>>>> resource object. You mentioned before that resources are persisted.
>>>> What is the (database) model for a resource? In your opinion, should
>>>> this be added to a static cdo hibernate mapping (meta.hbm.xml)?
>>> With CDO a Resource is really an ordinary persistent object much like
>>> any other EObject. I think there's no need to add it to the static
>>> meta model mapping. At least there was no need for the DBStore. I
>>> recall that the CDOResource class has only 2 non-transient features:
>>> path and contents. These should be mapped as normal for EObjects.
>> MT>> contents can contain any type of eobject from the model, right?
>> If the resource is also persisted then I can add it to the generated
>> mapping. I need to think about how to map the contents feature
>> (assuming that any type of eobject can be in the root of the resource).
> Do you mean "add it to the manually created mapping"?
> I think either approach is ok. I leave it up to you.
> The problem with EObject as target type for references could potentially
> occur at other model places as well, right? An internal flat technical
> key is practical for these cases ;-)
>
>
>>>> Hibernate works best if each type (eclass) also has a version
>>>> feature for handling optimistic locking. It also uses the version
>>>> property to detect if an object is new or not. In your testmodel
>>>> there is no version feature and not all types have a feature which
>>>> can be used for the id. Do you agree that I create a separate
>>>> testmodel which contains this info together with some teneo
>>>> annotations? It can be a copy of model1.
>>> The version is, much like the CDOID, an internal "feature" of each
>>> CDOObject:
>>>
>>> public interface CDOObject extends EObject
>>> {
>>> public CDOClass cdoClass();
>>> public CDOID cdoID();
>>> public CDOState cdoState();
>>> public CDOView cdoView();
>>> public CDOResource cdoResource();
>>> public CDORevision cdoRevision();
>>> }
>>>
>>> Of course you can create a separate test model if you think this is
>>> necessary ;-)
>> MT>> It is better if we can use the current native version support of
>> cdo. Below I see you can do cdoRevision.getVersion() to get the
>> version number.
> Right ;-)
>
>
> Cheers
> /Eike
>
>
>>>> Btw, I think you detect that an object is new by looking at the
>>>> cdoid, correct? Maybe we can use that in hibernate to detect
>>>> 'new-ness' instead of the version feature.
>>>
>>> Hmm, I think you're right. Currently I use something like
>>> revision.getID().isTemporary() which indicates if the object has a
>>> temporary id because it was newly created in a client side
>>> transaction. revision.getVersion() == 1 would have the same effect.
>> MT>> Okay
>>
>>>
>>> Cheers
>>> /EIke
>>
>>
--
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
|
|
|
Goto Forum:
Current Time: Thu Apr 18 06:55:29 GMT 2024
Powered by FUDForum. Page generated in 0.04423 seconds |
] 
Search
Help
Register
Login
Home
