Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Non-changeable containment references
Non-changeable containment references [message #633119] Fri, 15 October 2010 12:33 Go to next message
J.-P. Pellet is currently offline J.-P. PelletFriend
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.
Re: Non-changeable containment references [message #633123 is a reply to message #633119] Fri, 15 October 2010 12:39 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30653
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.
Re: Non-changeable containment references [message #633124 is a reply to message #633123] Fri, 15 October 2010 12:51 Go to previous messageGo to next message
J.-P. Pellet is currently offline J.-P. PelletFriend
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?
Re: Non-changeable containment references [message #633150 is a reply to message #633124] Fri, 15 October 2010 13:46 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30653
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?
Re: Non-changeable containment references [message #633183 is a reply to message #633150] Fri, 15 October 2010 14:47 Go to previous message
J.-P. Pellet is currently offline J.-P. PelletFriend
Messages: 71
Registered: July 2009
Member
> Yes, one would generally expect that isTransient is true when
> isChangeable is false.

Thanks for the clarification, Ed!
Previous Topic:Custom ResourceLocator for the generated Validator
Next Topic:model loading standalone application
Goto Forum:
  


Current Time: Thu Nov 21 10:43:46 GMT 2019

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

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

Back to the top