|
| Re: [CDO] Transactional Editing Domain [message #116340 is a reply to message #116330] |
Sat, 29 March 2008 14:35   |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Matthias,
Comments inline...
Matthias schrieb:
> Hello!
>
> I recently have read in a post that CDO does not work with GMF and
> therefore not with EMF transactions!
Basically I think it's just the other way round: It seems odd to have
two transactional layers on top of each other. That's the reason why EMF
Transaction has been reported not to work well on top of CDO (haven't
verified that but think that sounds reasonable). If GMF editors are
tightly coupled to EMF Transaction it follows that it also has a problem
to work with CDO.
Unfortunately I didn't have the time so far to really test/proof/fix all
these hypothesises. I'd really appreciate to work together with you to
find a solution if possible. Is your code confidential or could I have a
look at it and play with it?
> But I have the following scenario: I have a GMF editor and some model
> editor. For the model editing I am using CDO. I have references
> between the model entities in the GMF editor and in the model editor.
> So I have to use only one Editing Domain for both editors. I tried it,
> but when adding some data to a resource a get an exception "a resource
> set can only be modified within a write transaction".
>
> What do you think Eike?! Is my problem able?!? Because I dont think
> that proxies work between two EditingDomains and ResourceSets. Maybe
> this question goes also to the EMF experts!
Apart from my conceptual concerns with stacked transaction solutions it
should be basically possible to attach a CDO transaction to existing
ResourceSets. Although it has not been tested so far you could try the
following:
ResourceSet resourceSet = ...
CDOSession session = ...
CDOTransaction transaction = session.openTransaction(resourceSet);
...
transaction.commit();
session.close();
Do you plan to have both the model and the diagram be managed by CDO?
If not, there could be another issue with referencing CDO objects from
"outside" (here: the diagram).
The reason is that a CDO URI does not contain information about the
repository that the object lives in.
This information is externally contributed through the CDOSession that
is associated with the local ResourceSet.
GMF diagrams are again a good candidate to see if this is convenient or
can be made better.
Cheers
/Eike
>
>
> Best regards,
> Matthias
>
|
|
|
|
| Re: [CDO] Transactional Editing Domain [message #116591 is a reply to message #116499] |
Thu, 03 April 2008 08:10 |
|
Hi Matthias,
Comments inline...
Matthias wrote:
> Hello Eike!
> I am planning to use CDO for my whole domain model. So the best case would
> be if CDO can also handle the GMF related models (Notation model, etc. ->
> which are in fact legacy objects in CDO). So I am also looking forward
> that CDO can also work with GMF, even with my help!
I'll have time during the weekend to think about how we can start on this
subject.
> So currently I have to use Teneo in "combination" with CDO. I am using
> Teneo for persisting the GMF diagram model and the mapped domain model
> entities (not the whole domain model, only the entities that are defined
> in the gmfmap model).
> But there is another issue: I tried it, but I think it is not possible to
> have (containment) proxy references between a Teneo Resource and a CDO
> Resource. Say I have a "Container" inside a CDO Resource and a "Child"
> object which reside in the HibernateXMLResouce (Teneo)! Otherwise I have
> to store and manage two different objects with the same semantic data.
I have not thought about containment proxies in the context of CDO so far.
I'm not sure if I want to make CDO capable of handling contanment proxies
that refer to instances outside of the repository of the containing
instance. CDO does even not handle this case for ordinary cross
references. because a CDO repository is considered to be self contained.
Usually I suggest to represent such references by some other means, e.g.
some sort of scalar foreign key and a derived feature that calculates the
target reference from the foreign key (possibly plus some application
context information). Would that be suitable for your case?
> This would solve my problem! Or do we have any help from the the Teneo
> "integration" in CDO?!
As I understand it, no. The issue you describe is an EMF issue (or better:
a CDO issue with respect to EMF). The new Hibernate integration happens
only on the CDO server where there is no EMF.
> So summed up, yes I would like to use CDO for all the editing, but for now
> I think it is not possible!
I guesss no, not at the moment, but it will be cool to work together to
get at that state ;-)
Cheers
/Eike
> Best regards,
> Matthias
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: [CDO] Transactional Editing Domain [message #616032 is a reply to message #116330] |
Sat, 29 March 2008 14:35 |
|
Hi Matthias,
Comments inline...
Matthias schrieb:
> Hello!
>
> I recently have read in a post that CDO does not work with GMF and
> therefore not with EMF transactions!
Basically I think it's just the other way round: It seems odd to have
two transactional layers on top of each other. That's the reason why EMF
Transaction has been reported not to work well on top of CDO (haven't
verified that but think that sounds reasonable). If GMF editors are
tightly coupled to EMF Transaction it follows that it also has a problem
to work with CDO.
Unfortunately I didn't have the time so far to really test/proof/fix all
these hypothesises. I'd really appreciate to work together with you to
find a solution if possible. Is your code confidential or could I have a
look at it and play with it?
> But I have the following scenario: I have a GMF editor and some model
> editor. For the model editing I am using CDO. I have references
> between the model entities in the GMF editor and in the model editor.
> So I have to use only one Editing Domain for both editors. I tried it,
> but when adding some data to a resource a get an exception "a resource
> set can only be modified within a write transaction".
>
> What do you think Eike?! Is my problem able?!? Because I dont think
> that proxies work between two EditingDomains and ResourceSets. Maybe
> this question goes also to the EMF experts!
Apart from my conceptual concerns with stacked transaction solutions it
should be basically possible to attach a CDO transaction to existing
ResourceSets. Although it has not been tested so far you could try the
following:
ResourceSet resourceSet = ...
CDOSession session = ...
CDOTransaction transaction = session.openTransaction(resourceSet);
...
transaction.commit();
session.close();
Do you plan to have both the model and the diagram be managed by CDO?
If not, there could be another issue with referencing CDO objects from
"outside" (here: the diagram).
The reason is that a CDO URI does not contain information about the
repository that the object lives in.
This information is externally contributed through the CDOSession that
is associated with the local ResourceSet.
GMF diagrams are again a good candidate to see if this is convenient or
can be made better.
Cheers
/Eike
>
>
> Best regards,
> Matthias
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: [CDO] Transactional Editing Domain [message #616059 is a reply to message #116499] |
Thu, 03 April 2008 08:10 |
|
Hi Matthias,
Comments inline...
Matthias wrote:
> Hello Eike!
> I am planning to use CDO for my whole domain model. So the best case would
> be if CDO can also handle the GMF related models (Notation model, etc. ->
> which are in fact legacy objects in CDO). So I am also looking forward
> that CDO can also work with GMF, even with my help!
I'll have time during the weekend to think about how we can start on this
subject.
> So currently I have to use Teneo in "combination" with CDO. I am using
> Teneo for persisting the GMF diagram model and the mapped domain model
> entities (not the whole domain model, only the entities that are defined
> in the gmfmap model).
> But there is another issue: I tried it, but I think it is not possible to
> have (containment) proxy references between a Teneo Resource and a CDO
> Resource. Say I have a "Container" inside a CDO Resource and a "Child"
> object which reside in the HibernateXMLResouce (Teneo)! Otherwise I have
> to store and manage two different objects with the same semantic data.
I have not thought about containment proxies in the context of CDO so far.
I'm not sure if I want to make CDO capable of handling contanment proxies
that refer to instances outside of the repository of the containing
instance. CDO does even not handle this case for ordinary cross
references. because a CDO repository is considered to be self contained.
Usually I suggest to represent such references by some other means, e.g.
some sort of scalar foreign key and a derived feature that calculates the
target reference from the foreign key (possibly plus some application
context information). Would that be suitable for your case?
> This would solve my problem! Or do we have any help from the the Teneo
> "integration" in CDO?!
As I understand it, no. The issue you describe is an EMF issue (or better:
a CDO issue with respect to EMF). The new Hibernate integration happens
only on the CDO server where there is no EMF.
> So summed up, yes I would like to use CDO for all the editing, but for now
> I think it is not possible!
I guesss no, not at the moment, but it will be cool to work together to
get at that state ;-)
Cheers
/Eike
> Best regards,
> Matthias
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Powered by
FUDForum. Page generated in 0.02540 seconds
] 
Search
Help
Register
Login
Home
