Home » Modeling » EMF » New Ecore container-reference validation rule in Helios: Bug?
| New Ecore container-reference validation rule in Helios: Bug? [message #548347] |
Wed, 21 July 2010 14:00  |
|
Hi,
Today was my first time re-generating a model with the Helios final
build since the last time I re-generated, with Helios M6. In opening my
genmodel, I got this error reported:
A containment reference of a type with a container feature
platform:/resource/com.qnx.tools.ide.systembuilder.model/mod el/System.ecore#//Condition/constraint
that requires instances to be contained elsewhere cannot be populated.
In my case, I think this validation problem is erroneous.
I have two questions:
(a) Container references are derived by being the opposites of
containments, so it is not possible that an object can
have a value for the container that is inconsistent with
its containment. Doesn't the generated code for the
container reference check the actual eContainmentFeature()
and, if it's not the container's opposite, return null?
(b) Container references don't have to have non-null values,
right? I can have many container references, with
zero or one of them having a value, but not more?
My situation is like this:
Class Super {
contains x[*] : X
}
Class X {
references super[0..1] : Super opposite-of contains
}
Class Sub -> Super {
contains otherRoleForX[1..*] : X
}
So, X::super is a container reference because it's the opposite of a
containment.
The validation rule complains that Sub::otherRoleForX is not a valid
containment because X::super is of type Super, but that's OK because
X::super doesn't have a value *unless* the object is contained via Super::x.
I don't see how this validation rule makes sense. Can I turn it off,
somehow?
Thanks,
Christian
|
|
|
| Re: New Ecore container-reference validation rule in Helios: Bug? [message #548349 is a reply to message #548347] |
Wed, 21 July 2010 14:35  |
 Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Christian,
Comments below.
Christian W. Damus wrote:
> Hi,
>
> Today was my first time re-generating a model with the Helios final
> build since the last time I re-generated, with Helios M6. In opening
> my genmodel, I got this error reported:
>
> A containment reference of a type with a container feature
> platform:/resource/com.qnx.tools.ide.systembuilder.model/mod el/System.ecore#//Condition/constraint
> that requires instances to be contained elsewhere cannot be populated.
That looks familiar.
>
> In my case, I think this validation problem is erroneous.
Hmmm...
>
> I have two questions:
>
> (a) Container references are derived by being the opposites of
> containments, so it is not possible that an object can
> have a value for the container that is inconsistent with
> its containment.
Indeed.
> Doesn't the generated code for the
> container reference check the actual eContainmentFeature()
> and, if it's not the container's opposite, return null?
Yes.
>
> (b) Container references don't have to have non-null values,
> right? I can have many container references, with
> zero or one of them having a value, but not more?
Yes.
>
> My situation is like this:
>
> Class Super {
> contains x[*] : X
> }
>
> Class X {
> references super[0..1] : Super opposite-of contains
> }
>
> Class Sub -> Super {
> contains otherRoleForX[1..*] : X
> }
>
> So, X::super is a container reference because it's the opposite of a
> containment.
>
> The validation rule complains that Sub::otherRoleForX is not a valid
> containment because X::super is of type Super, but that's OK because
> X::super doesn't have a value *unless* the object is contained via
> Super::x.
It's complaining about the multiplicities of the container references so
I doubt your example is accurate. I don't see any required containers.
Consider the implementation:
public boolean validateEReference_ConsistentContainer(EReference
eReference, DiagnosticChain diagnostics, Map<Object, Object> context)
{
if (eReference.isContainment() && eReference.getEContainingClass()
!= null)
{
EClass eClass = eReference.getEReferenceType();
if (eClass != null)
{
for (EReference otherEReference : eClass.getEAllReferences())
{
if (otherEReference.isRequired() &&
otherEReference.isContainer() && otherEReference.getEOpposite() !=
eReference)
{
The point is supposed to be that you can't be contained by more than one
container, so you can't have a container references that's required as
well as any other containment reference that's not the opposite of that
required container. I.e., a required container prevents other
containment references from ever being populated.
>
> I don't see how this validation rule makes sense. Can I turn it off,
> somehow?
No, but I can fix it if it's broken. It seems sound though...
>
> Thanks,
>
> Christian
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: New Ecore container-reference validation rule in Helios: Bug? [message #548362 is a reply to message #548349] |
Wed, 21 July 2010 14:51 |
|
Hi, Ed,
You are so right! Dang, will I *never* find a bug in EMF? ;-)
I hadn't paid the multiplicity any attention because it never really did
matter for containers (at least, not for codegen). But, this new
validation rule pointed out the erroneous 1 lower-bound in my model that
I didn't know was there ... I had assumed it was what I expected.
Great rule! Keep them coming!
Thanks,
Christian
On 21/07/10 10:35 AM, Ed Merks wrote:
-------->8--------
>> The validation rule complains that Sub::otherRoleForX is not a valid
>> containment because X::super is of type Super, but that's OK because
>> X::super doesn't have a value *unless* the object is contained via
>> Super::x.
> It's complaining about the multiplicities of the container references so
> I doubt your example is accurate. I don't see any required containers.
> Consider the implementation:
--------8<--------
|
|
|
| Re: New Ecore container-reference validation rule in Helios: Bug? [message #548370 is a reply to message #548362] |
Wed, 21 July 2010 15:08 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Christian,
I had the same experience with the GenModel itself. A GenPackage was
required to be contained by a GenModel, which overlooked the fact that
it can be contained by a GenPackage instead.
Christian W. Damus wrote:
> Hi, Ed,
>
> You are so right! Dang, will I *never* find a bug in EMF? ;-)
>
> I hadn't paid the multiplicity any attention because it never really
> did matter for containers (at least, not for codegen). But, this new
> validation rule pointed out the erroneous 1 lower-bound in my model
> that I didn't know was there ... I had assumed it was what I expected.
>
> Great rule! Keep them coming!
>
> Thanks,
>
> Christian
>
>
> On 21/07/10 10:35 AM, Ed Merks wrote:
>
> -------->8--------
>
>>> The validation rule complains that Sub::otherRoleForX is not a valid
>>> containment because X::super is of type Super, but that's OK because
>>> X::super doesn't have a value *unless* the object is contained via
>>> Super::x.
>> It's complaining about the multiplicities of the container references so
>> I doubt your example is accurate. I don't see any required containers.
>> Consider the implementation:
>
> --------8<--------
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: New Ecore container-reference validation rule in Helios: Bug? [message #663573 is a reply to message #663515] |
Tue, 05 April 2011 16:12 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Mario,
Comments below.
Mario Winterer wrote:
> Hi!
>
> Shouldn't container references always be nullable anyway?
No, why?
> Objects can sometimes get a container that they aren't aware of.
That's true.
> E.g. ChangeDescription#objectstoAttach contains all objects that were
> removed from its model, so an object with non-nullable container
> references will never be valid once inside a ChangeDescription.
That's certainly true. But consider something like an EClass instance.
It really needs to be in an EPackage to be valid. Floating around in a
ChangeDescription isn't good enough...
> I mean for the sake of (re)usability an object's container can and
> should never be restricted by the model designer, and the same should
> be true for its container references.
I don't think that's a good assertion. I think it's often the case for
something to be semantically complete that it needs to exist in a
complete context.
Your example about being in a change description is a good one though.
But even here, a new object might exist in a form that leaves it
incomplete but the change description includes feature changes that when
applied will move the object to a complete context and will set all the
features to make it valid. So in general, it will often be the case
that an object contained in a change description will not be valid in
that state...
>
> Mario
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Nov 09 01:09:37 GMT 2024
Powered by FUDForum. Page generated in 0.24211 seconds |
] 
Search
Help
Register
Login
Home
