Home » Modeling » EMF » Transient eOpposite of a persistent eRef?
| |
| Re: Transient eOpposite of a persistent eRef? [message #648402 is a reply to message #648182] |
Wed, 12 January 2011 17:38   |
 Hallvard Traetteberg
Messages: 673
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 #648405 is a reply to message #648402] |
Wed, 12 January 2011 17:54 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Transient eOpposite of a persistent eRef? [message #649208 is a reply to message #648403] |
Tue, 18 January 2011 08:13 |
Hallvard Traetteberg
Messages: 673
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 15:59 |
Ed Merks
Messages: 33137
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Transient eOpposite of a persistent eRef? [message #1053230 is a reply to message #648124] |
Fri, 03 May 2013 09:27 |
Cristian Spiescu
Messages: 100
Registered: July 2009 |
Senior 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 09:49 |
Ed Merks
Messages: 33137
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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 23:22:19 GMT 2024
Powered by FUDForum. Page generated in 0.03799 seconds |
] 
Search
Help
Register
Login
Home
