| [Basic EMF] Delete Command and references question [message #426087] |
Tue, 16 December 2008 04:06  |
Eclipse User |
|
|
|
Hello,
when looking at the source code of the DeleteCommand, the references to
the object, which is to be deleted, get only removed when the reference
cardianlity is many (see if stmt in line 150 in DeleteCommand.java),
otherwise the reference is set to null (line 156). But why does this
restriction(?) exist?!?
Use case: In my project I have two models A and B. B has a non-containment
reference to A with cardinality 0..1 . When deleting A, B does not get
removed because of the 0..1 cardinality. If it were 0..n then it would (as
far as I understand the code)!
Bye,
Matthias
|
|
|
| Re: [Basic EMF] Delete Command and references question [message #426096 is a reply to message #426087] |
Tue, 16 December 2008 05:25  |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------000202070605030108090102
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Matthias,
Comments below.
Matthias Treitler wrote:
> Hello,
>
> when looking at the source code of the DeleteCommand, the references
> to the object, which is to be deleted, get only removed when the
> reference cardianlity is many (see if stmt in line 150 in
> DeleteCommand.java), otherwise the reference is set to null (line
> 156). But why does this restriction(?) exist?!?
I'm not sure why you consider it a "restriction"?
> Use case: In my project I have two models A and B. B has a
> non-containment reference to A with cardinality 0..1 . When deleting
> A, B does not get removed because of the 0..1 cardinality.
I'm not sure I follow this "removed" comment here. B should not be
removed at all. B's reference to A should be set to null though, or
with the latest version of EMF, should be set to the
SetCommand.UNSET_VALUE (to unset it).
> If it were 0..n then it would (as far as I understand the code)!
Consider that one of two patterns applies depending on the multiplicity
of the feature:
((List<?>)eObject.eGet(feature)).remove(value)
or
eObject.eUnset(feature)
That's why the delete code looks the way it does....
>
> Bye, Matthias
>
--------------000202070605030108090102
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Matthias,<br>
<br>
Comments below.<br>
<br>
Matthias Treitler wrote:
<blockquote
cite="mid:3f6321cc5ab86e4ec3679d91bec72105$1@www.eclipse.org"
type="cite">Hello,
<br>
<br>
when looking at the source code of the DeleteCommand, the references to
the object, which is to be deleted, get only removed when the reference
cardianlity is many (see if stmt in line 150 in DeleteCommand.java),
otherwise the reference is set to null (line 156). But why does this
restriction(?) exist?!? <br>
</blockquote>
I'm not sure why you consider it a "restriction"?<br>
<blockquote
cite="mid:3f6321cc5ab86e4ec3679d91bec72105$1@www.eclipse.org"
type="cite">Use case: In my project I have two models A and B. B has a
non-containment reference to A with cardinality 0..1 . When deleting A,
B does not get removed because of the 0..1 cardinality.</blockquote>
I'm not sure I follow this "removed" comment here.
|
|
|
Powered by
FUDForum. Page generated in 0.03584 seconds
Home