| Location of Containment Proxy Objects [message #1857873] |
Fri, 03 March 2023 03:27  |
|
If I have an EObject O in resource A in a containment reference that allows proxies, and I decided to store the EObject in resource B, will O then automatically be located in the root of B, i.e. is O always a direct content of B?
I am asking because an EObject can only have one container. If the container reference points to the containing object of O, and the containing reference is in A, there can be no EObject in B that can have O in its contents.
So it seems the only place for O in B is in the list of direct contents. These EObjects have a resource, but no container.
Is that true, or have I gone wrong in my logic somewhere?
|
|
|
| Re: Location of Containment Proxy Objects [message #1857875 is a reply to message #1857873] |
Fri, 03 March 2023 06:43  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Any given EObject O, O.eResource is of course unique. ((InternalEObject)0).eDirectResource()) != null if O is the directly contained by a Resource. O.eResource is computed by walking ((InternalEObject)0).eInternalContainer()), walking up the containers without resolving proxies, until ((InternalEObject)0).eDirectResource()) != null. It is not necessarily the case that O.eResource() == O.eContainer().eResource(), and both ((InternalEObject)0).eDirectResource()) != null and O.eContainer() != null can be true. I.e., a child of a containment reference, i.e., any EObject in O.eContents(), can be directly contained by a different resource. That's why there are methods like org.eclipse.emf.ecore.util.EcoreUtil.getAllProperContents(EObject, boolean) versus org.eclipse.emf.ecore.util.EcoreUtil.getAllContents(EObject, boolean).
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Location of Containment Proxy Objects [message #1857879 is a reply to message #1857875] |
Fri, 03 March 2023 10:50 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Your questions have answers that are necessary corollaries of the single containment principle of UML and Ecore.
Clearly the root (the Model) in UML cannot have a container; it is managed by the rather vague Extent. EMF makes the plausible design choice that a Resource has contents but is not a model object and so is not a container. (An alternate design choice could have treated a Resource as a model object and the ResourceSet as the not-container.)
The not-container Resource supports the ability to partition a large Resource into a root Resource and sub-Resources by proxying containment relationships. Since this is an implementation detail, it must be invisible to regular model activities, so the proxy must be the containment, and so the target must be not-contained in the sub-Resource, so yes it must be at the root of the sub-Resource.
This is fine provided the Resource and its sub-Resources form a single logical Resource. If you try to subvert this by sharing a sub-Resource in multiple logical Resources, EMF validation within the Sample Ecore Editor will rap you over the knuckles. For a bi-directional containment, even if the container is transient, the second logical Resource will report an inconsistent opposite. For unidirectional containment, the Sample Ecore Model Editor appears happy to allow the sharing and there is no 'modeling' violation since the multi-containment is not a modeled relationship. Similarly if you load two overlapping logical Resources programmatically everything appears to work. eContainer() returns the first. However if you validate, the inconsistent opposite associated with the multi-containment is diagnosed. Overlapping sub-Resources are diagnosed and so not supported; just as the single containment principle requires.
|
|
|
| Re: Location of Containment Proxy Objects [message #1857896 is a reply to message #1857879] |
Sat, 04 March 2023 23:04 |
|
Hello Eds (is that an acceptable efficiency?)
Thank you so much for your responses, which in summary answer my question very well. I would reflect:
[LIST TYPE=square]
[*] When an EObject is resolved from a containment proxy, then it will be a directly contained in the resource it resides in. I.e. it will be a root content object of the resource.
[*] This is logically necessary, because every EObject can only be contained by at most one other object.
[*] This also implies that you cannot have 'shared model fragments' pointed to from two locations, or mutual containments.
[*] The resulting validation rule is challenging to check, and there are a number of cases to watch. Validation with the basic validator will reveal issues.
[LIST]
|
|
|
Powered by
FUDForum. Page generated in 0.02545 seconds
] 
Search
Help
Register
Login
Home
