Eclipse Community Forums: EMF » Non-changeable containment references

Help

Home

Home » Modeling » EMF » Non-changeable containment references

Show: Today's Messages :: Show Polls :: Message Navigator

Non-changeable containment references [message #633119]

Fri, 15 October 2010 12:33

J.-P. Pellet

Messages: 71
Registered: July 2009

Member

Hi,

I found out something counterintuitive about non-changeable containment
EReferences.

Say class A has such a reference on an instance of class B:

/**
* @model changeable="false" containment="true"
*/
B getB();

As there's no generated setter setB(), I set the value of the
corresponding field directly in the constructor by assignment, "b =
whatever". So far, so good. Now, if I try saving the container object
"a", I'll get an exception that the referenced object b is not in the
resource set.

I would expect the system to realize that as the "b" reference in A in a
containment reference, then adding a to a resource set would also add
a.b transitively. To fix that, I had to make the feature changeable and
call the generated setter (which I can still hide with
suppressedSetVisibility="true").

Am I doing this correctly? Is there no way to keep the feature really
non-changeable and still as indicating containment, and get this to work
with serialization?

Best,
J.-P.

Report message to a moderator

Re: Non-changeable containment references [message #633123 is a reply to message #633119]

Fri, 15 October 2010 12:39

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

J.-P.

I imagine it can't be easy to populate a non-changeable containment
reference. More comments below...

J.-P. Pellet wrote:
> Hi,
>
> I found out something counterintuitive about non-changeable
> containment EReferences.
>
> Say class A has such a reference on an instance of class B:
>
> /**
> * @model changeable="false" containment="true"
> */
> B getB();
>
> As there's no generated setter setB(), I set the value of the
> corresponding field directly in the constructor by assignment, "b =
> whatever". So far, so good.
It's not sounding good to me.
> Now, if I try saving the container object "a", I'll get an exception
> that the referenced object b is not in the resource set.
Given that the opposite hasn't been set, i.e., eContainer is null, I'd
expect that.
>
> I would expect the system to realize that as the "b" reference in A in
> a containment reference, then adding a to a resource set would also
> add a.b transitively.
That's normally the case, but it's the case by virtue of the eContainer
being populated.
> To fix that, I had to make the feature changeable and call the
> generated setter (which I can still hide with
> suppressedSetVisibility="true").
Yes and if you looked at what the setter does, you'd see it does more
than just assign to the field.
>
> Am I doing this correctly? Is there no way to keep the feature really
> non-changeable and still as indicating containment, and get this to
> work with serialization?
What exactly will happen during deserialization? If you write it out,
you should expect to read it back in...
>
> Best,
> J.-P.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Non-changeable containment references [message #633124 is a reply to message #633123]

Fri, 15 October 2010 12:51

J.-P. Pellet

Messages: 71
Registered: July 2009

Member

>> I would expect the system to realize that as the "b" reference in A in
>> a containment reference, then adding a to a resource set would also
>> add a.b transitively.
> That's normally the case, but it's the case by virtue of the eContainer
> being populated.

I see.

>> Am I doing this correctly? Is there no way to keep the feature really
>> non-changeable and still as indicating containment, and get this to
>> work with serialization?
> What exactly will happen during deserialization? If you write it out,
> you should expect to read it back in...

Hmm, indeed. Thanks for pointing this out... But now I'm confused: this
implies that non-changeable features simply cannot be deserialized, right?

Report message to a moderator

Re: Non-changeable containment references [message #633150 is a reply to message #633124]

Fri, 15 October 2010 13:46

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

J.-P.,

Yes, one would generally expect that isTransient is true when
isChangeable is false.

J.-P. Pellet wrote:
>>> I would expect the system to realize that as the "b" reference in A in
>>> a containment reference, then adding a to a resource set would also
>>> add a.b transitively.
>> That's normally the case, but it's the case by virtue of the eContainer
>> being populated.
>
> I see.
>
>>> Am I doing this correctly? Is there no way to keep the feature really
>>> non-changeable and still as indicating containment, and get this to
>>> work with serialization?
>> What exactly will happen during deserialization? If you write it out,
>> you should expect to read it back in...
>
> Hmm, indeed. Thanks for pointing this out... But now I'm confused:
> this implies that non-changeable features simply cannot be
> deserialized, right?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator