Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Transient eOpposite of a persistent eRef?
Transient eOpposite of a persistent eRef? [message #648124] Tue, 11 January 2011 05:44 Go to next message
Caspar D. is currently offline Caspar D.
Messages: 35
Registered: July 2009
Member
Generally speaking, does it ever make sense to have transient=true
for the eOpposite of a *persistent* eRef? Or is this a modeling
error?

To me it doesn't seem to make much sense. If one end is persisted,
the eOpposite cannot vary independently anyway... so why make
it transient? But I may be overlooking something.

Nevertheless, it appears that transient eOpposites are supported in EMF.
But they're not necessarily easy to support in CDO, since CDO
must deal with partially loaded graphs. So before I try to think of a
way to get this working, I'd like to hear if it even makes any sense.
Re: Transient eOpposite of a persistent eRef? [message #648182 is a reply to message #648124] Tue, 11 January 2011 11:21 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Caspar,

Comments below.

Caspar D. wrote:
> Generally speaking, does it ever make sense to have transient=true
> for the eOpposite of a *persistent* eRef? Or is this a modeling
> error?
If the reference isn't proxy resolving then the reference will have to
be in the same resource and one could expect a deserializer to fully
populate both ends by populating just one end.
>
> To me it doesn't seem to make much sense. If one end is persisted,
> the eOpposite cannot vary independently anyway... so why make
> it transient? But I may be overlooking something.
>
> Nevertheless, it appears that transient eOpposites are supported in
> EMF. But they're not necessarily easy to support in CDO, since CDO
> must deal with partially loaded graphs. So before I try to think of a
> way to get this working, I'd like to hear if it even makes any sense.
I suppose a repository is almost like a single giant resource where one
wouldn't need to redundantly store information about both ends of the
reference. In the end, is the client really aware of the persistent
storage details? Certainly a client that makes one end of a
bidirectional reference transient is expecting that reference to behave
is if it weren't transient, so a simple solution is to treat
bidirectional references as transient only when both ends are transient...
Re: Transient eOpposite of a persistent eRef? [message #648402 is a reply to message #648182] Wed, 12 January 2011 12:38 Go to previous messageGo to next message
Hallvard Traetteberg is currently offline Hallvard Traetteberg
Messages: 594
Registered: July 2009
Location: Trondheim, Norway
Senior Member
On 11.01.11 17.21, Ed Merks wrote:
> Caspar,
>
> Comments below.
>
> Caspar D. wrote:
>> Generally speaking, does it ever make sense to have transient=true
>> for the eOpposite of a *persistent* eRef? Or is this a modeling
>> error?
> If the reference isn't proxy resolving then the reference will have to
> be in the same resource and one could expect a deserializer to fully
> populate both ends by populating just one end.

I have considered a setup where this seem to make sense:
I have many independent graph in separate resource, which can be
considered independent models. I want a separate 'parent' resource to
refer to these using containment, so that they seem to be within the
parent, but still possible to load independently. I.e. the parent's
containment reference must have transient = false (and resolve proxies),
while the eOpposite eContainer from the root of the independent trees to
the parent must have transient = true. Hence, if I load the independent
trees, they don't load the parent, while the parent loads the children.

Hallvard
Re: Transient eOpposite of a persistent eRef? [message #648403 is a reply to message #648402] Wed, 12 January 2011 12:52 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010104090100050605000507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hallvard,

Comments below.


Hallvard Tr
Re: Transient eOpposite of a persistent eRef? [message #648405 is a reply to message #648402] Wed, 12 January 2011 12:54 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5499
Registered: July 2009
Senior Member
Hi Hallvard,

I may be wrong but I think container references implicitely share the persistence settings of their containment opposite.
Cheers
/Eike

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



Am 12.01.2011 18:38, schrieb Hallvard Trætteberg:
> On 11.01.11 17.21, Ed Merks wrote:
>> Caspar,
>>
>> Comments below.
>>
>> Caspar D. wrote:
>>> Generally speaking, does it ever make sense to have transient=true
>>> for the eOpposite of a *persistent* eRef? Or is this a modeling
>>> error?
>> If the reference isn't proxy resolving then the reference will have to
>> be in the same resource and one could expect a deserializer to fully
>> populate both ends by populating just one end.
>
> I have considered a setup where this seem to make sense:
> I have many independent graph in separate resource, which can be considered independent models. I want a separate 'parent' resource to refer to these using containment, so that they seem to be within the parent, but still possible to load independently. I.e. the parent's containment reference must have transient = false (and resolve proxies), while the eOpposite eContainer from the root of the independent trees to the parent must have transient = true. Hence, if I load the independent trees, they don't load the parent, while the parent loads the children.
>
> Hallvard
Re: Transient eOpposite of a persistent eRef? [message #649208 is a reply to message #648403] Tue, 18 January 2011 03:13 Go to previous messageGo to next message
Hallvard Traetteberg is currently offline Hallvard Traetteberg
Messages: 594
Registered: July 2009
Location: Trondheim, Norway
Senior Member
On 12.01.11 18.52, Ed Merks wrote:
>>
>> I have considered a setup where this seem to make sense:
>> I have many independent graph in separate resource, which can be
>> considered independent models. I want a separate 'parent' resource to
>> refer to these using containment,
> Why containment?

It's a model of a widget hierarchy, and I want to be able to split
existing models into parent/child parts, i.e. cut off arbitrary branches
and put them into a separate resources while still being contained by
their parents. These separate widget containers must be loadable without
loading the rest the parent. BTW, I don't need to model the parent
reference, but I guess the eContainer is automatically the eOpposite of
the containment reference.

>> so that they seem to be within the parent, but still possible to load
>> independently.
> Non-containment would work perfectly for that.
>> I.e. the parent's containment reference must have transient = false
>> (and resolve proxies), while the eOpposite eContainer from the root of
>> the independent trees to the parent must have transient = true. Hence,
>> if I load the independent trees, they don't load the parent, while the
>> parent loads the children.

Hallvard
Re: Transient eOpposite of a persistent eRef? [message #649291 is a reply to message #649208] Tue, 18 January 2011 10:59 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Hallvard,

Comments below.

Hallvard Trætteberg wrote:
> On 12.01.11 18.52, Ed Merks wrote:
>>>
>>> I have considered a setup where this seem to make sense:
>>> I have many independent graph in separate resource, which can be
>>> considered independent models. I want a separate 'parent' resource to
>>> refer to these using containment,
>> Why containment?
>
> It's a model of a widget hierarchy, and I want to be able to split
> existing models into parent/child parts, i.e. cut off arbitrary
> branches and put them into a separate resources while still being
> contained by their parents. These separate widget containers must be
> loadable without loading the rest the parent.
That seems reasonable. Note that it's always possible to load without
loading any references. In fact it's only as you traverse references
that proxies are resolved and of course it's possible to traverse
references without resolving proxies as well.
> BTW, I don't need to model the parent reference, but I guess the
> eContainer is automatically the eOpposite of the containment reference.
Yes, containments always have eContainer as their implicit opposite.
>
>>> so that they seem to be within the parent, but still possible to load
>>> independently.
>> Non-containment would work perfectly for that.
>>> I.e. the parent's containment reference must have transient = false
>>> (and resolve proxies), while the eOpposite eContainer from the root of
>>> the independent trees to the parent must have transient = true. Hence,
>>> if I load the independent trees, they don't load the parent, while the
>>> parent loads the children.
>
> Hallvard
Re: Transient eOpposite of a persistent eRef? [message #1053230 is a reply to message #648124] Fri, 03 May 2013 05:27 Go to previous messageGo to next message
Cristian Mising name is currently offline Cristian Mising name
Messages: 74
Registered: July 2009
Member
Hello,

I continue this thread, because I have a question on this particular topic.

a) I have several resources that contain UML-like model elements (Class, attribute, etc)
b) I have a diagram that contains notation model elements that reference the above UML-like model elements. So far so good, we need an uni-directional reference.
c) I want to be able to navigate rapidly from the UML-like model elements to the corresponding diagrams. So the uni-directional reference above, becomes bi-directional; e.g. a list called "diagrams".
d) But the above reference: I want it to be transient, so that my resources (with UML-like model elements) don't depend on the diagrams.

What I would like:
when I load an UML-like model element:
1) if no diagrams are loaded => the list "diagrams" is empty
2) if I load a diagram that references this model element, then I would like my transient list to contain the newly loaded diagram.

The question:

I can achieve this, by modifying the generated setter of the diagram/notation model elements: if the EObject parameter is proxy => resolve it before setting it. This would ensure that during load of the diagram, all proxies are resolved, so the transient list is correctly populated.

Are there pitfalls related to this approach? I.e. resolving a EObject proxy in the setter?

Thank you in advance.

Regards,
Cristian.
Re: Transient eOpposite of a persistent eRef? [message #1053233 is a reply to message #1053230] Fri, 03 May 2013 05:49 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 25999
Registered: July 2009
Senior Member
Cristian,

Comments below.

On 03/05/2013 11:27 AM, Cristian Mising name wrote:
> Hello,
>
> I continue this thread, because I have a question on this particular
> topic.
>
> a) I have several resources that contain UML-like model elements
> (Class, attribute, etc)
> b) I have a diagram that contains notation model elements that
> reference the above UML-like model elements. So far so good, we need
> an uni-directional reference.
> c) I want to be able to navigate rapidly from the UML-like model
> elements to the corresponding diagrams. So the uni-directional
> reference above, becomes bi-directional; e.g. a list called "diagrams".
This is not a good idea. Suppose one said "I always want to rapidly
navigate both directions of all references" one could conclude, "there
all references because directional" but this is simply an unworkable
solution. An example of this is like EClass.eSuperTypes. Sure it's
quite often I want to navigate to all subclass, but it's still not
reasonable to make this reference bidirectional. We can't expect that
an EClass will always know all subclasses. It just can't know that and
it can't be expected to store such information.
> d) But the above reference: I want it to be transient, so that my
> resources (with UML-like model elements) don't depend on the diagrams.
See, you're going down a rat hole now... The model should not even know
about diagrams...
> What I would like: when I load an UML-like model element:
> 1) if no diagrams are loaded => the list "diagrams" is empty
> 2) if I load a diagram that references this model element, then I
> would like my transient list to contain the newly loaded diagram.
Yes, you might like that, but it's not a reasonable expectation.
>
> The question:
>
> I can achieve this, by modifying the generated setter of the
> diagram/notation model elements: if the EObject parameter is proxy =>
> resolve it before setting it. This would ensure that during load of
> the diagram, all proxies are resolved, so the transient list is
> correctly populated.
No, it's a rat hole. You'll die down there.
> Are there pitfalls related to this approach? I.e. resolving a EObject
> proxy in the setter?
>
This is the type of thing that an ECrossReferenceAdapter is for, i.e.,
rapid inverse navigation of unidirectional references.
>
> Thank you in advance.
>
> Regards,
> Cristian.
Re: Transient eOpposite of a persistent eRef? [message #1053262 is a reply to message #1053233] Fri, 03 May 2013 08:52 Go to previous message
Cristian Mising name is currently offline Cristian Mising name
Messages: 74
Registered: July 2009
Member
Dear Ed,

Thank you for your input!

I was originally interested in having references with one end transient and one end persistent because my code is used both within EMF XML resources and in the DB (with Teneo). It seemed a solution to have common code for all operations.

In the light of what you are saying, I think is better to use the ECrossReferenceAdapter for the XML Resources (i.e. model loaded in memory all time), and some other mechanism for DB version (where the adapter is not usable, because only a small part of the model is in memory).

Thanks again!

Best regards,
Cristian.
Previous Topic:Map keys shall be only attributes of an EClass
Next Topic:Existing Java Source Code to EMF model
Goto Forum:
  


Current Time: Thu Aug 21 08:14:32 EDT 2014

Powered by FUDForum. Page generated in 0.03073 seconds