Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
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 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
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 #663515 is a reply to message #548370] Tue, 05 April 2011 13:22 Go to previous messageGo to next message
Mario Winterer is currently offline Mario WintererFriend
Messages: 136
Registered: July 2009
Senior Member
Hi!

Shouldn't container references always be nullable anyway?
Objects can sometimes get a container that they aren't aware of.
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.
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.

Mario
Re: New Ecore container-reference validation rule in Helios: Bug? [message #663573 is a reply to message #663515] Tue, 05 April 2011 16:12 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
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/
Previous Topic:TreeViewer setInput error
Next Topic:Separating API from Implementation in Model
Goto Forum:
  


Current Time: Fri Mar 29 01:11:02 GMT 2024

Powered by FUDForum. Page generated in 0.03443 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top