Home » Modeling » EMF » Recursive models
| Recursive models [message #399282] |
Sat, 11 March 2006 13:57  |
Eclipse User |
|
|
|
Hello,
I have a book which contains sections. Sections can contain sections.
For easier navigation, every section has a reference to the book.
Now, I'm running into problems: When I call setBook(), the
eContainerFeatureID is set to a negative value in
EcoreEList.inverseAdd() which causes getBook() to always return null:
public IBook getBook()
{
if (eContainerFeatureID != ModelPackage.SECTION__BOOK) return null;
return (IBook)eContainer();
}
I understand that the code in inverseAdd() tries to flag the fact that
the book has no inverse mapping to section (because some sections are no
direct children of the book).
How do I fix this?
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/
|
|
| | |
| Re: Recursive models [message #399296 is a reply to message #399288] |
Mon, 13 March 2006 07:43  |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------060907020805080201010608
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Aaron,
I think your expectations are the problem and I'm not sure what you show
below is accurate. It seemed pretty clear from the generated code that
"book" is a container reference which must be the opposite of a
containment reference, but you aren't showing it having an opposite
below. The only way to achieve what you want (a reference that returns
the closest containing book) is to do what Eike said, i.e., you can
model it, but you have to implement the behavior by hand. (It will
often be the case that the eContainer will be a Section and hence you'll
often need to call eContainer() repeatedly until you get to a Book.)
Aaron Digulla wrote:
>Eike Stepper wrote:
>
>
>
>>If your sections are not nested too deeply in average, it might be a
>>choice to
>>model a derived (computed on the fly) reference section -> book which
>>follows the path up section -> section -> book.
>>
>>Mark this reference derived, transient and volatile and change the
>>generated method.
>>
>>
>
>I can fix the problem by just checking if eContainer() is a book but
>that doesn't solve the bug. Why is EMF generating code that doesn't
>work? Or am I doing something wrong?
>
>Here is the definition of book:
>
> <eStructuralFeatures xsi:type="ecore:EReference" name="book"
>lowerBound="1" eType="#//Book"/>
>
>I update this field myself when I create new sections but getBook()
>always returns null.
>
>
>
>>Aaron Digulla schrieb:
>>
>>
>>>Hello,
>>>
>>>I have a book which contains sections. Sections can contain sections.
>>>
>>>For easier navigation, every section has a reference to the book.
>>>
>>>Now, I'm running into problems: When I call setBook(), the
>>>eContainerFeatureID is set to a negative value in
>>>EcoreEList.inverseAdd() which causes getBook() to always return null:
>>>
>>> public IBook getBook()
>>> {
>>> if (eContainerFeatureID != ModelPackage.SECTION__BOOK) return
>>>null;
>>> return (IBook)eContainer();
>>> }
>>>
>>>I understand that the code in inverseAdd() tries to flag the fact that
>>>the book has no inverse mapping to section (because some sections are no
>>>direct children of the book).
>>>
>>>How do I fix this?
>>>
>>>
>>>
>
>
>
>
--------------060907020805080201010608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Aaron,<br>
<br>
I think your expectations are the problem and I'm not sure what you
show below is accurate. It seemed pretty clear from the generated code
that
"book" is a container reference which must be the opposite of a
containment reference, but you aren't showing it having an opposite
below. The only way to achieve what you want (a reference that returns
the closest containing book) is to do what Eike said, i.e., you can
model it, but you have to implement the behavior by hand. (It will
often be the case that the eContainer will be a Section and hence
you'll often need to call eContainer() repeatedly until you get to a
Book.)<br>
<br>
<br>
Aaron Digulla wrote:
<blockquote cite="middv2111$89p$1@utils.eclipse.org" type="cite">
<pre wrap="">Eike Stepper wrote:
</pre>
<blockquote type="cite">
<pre wrap="">If your sections are not nested too deeply in average, it might be a
choice to
model a derived (computed on the fly) reference section -> book which
follows the path up section -> section -> book.
Mark this reference derived, transient and volatile and change the
generated method.
</pre>
</blockquote>
<pre wrap=""><!---->
I can fix the problem by just checking if eContainer() is a book but
that doesn't solve the bug. Why is EMF generating code that doesn't
work? Or am I doing something wrong?
Here is the definition of book:
<eStructuralFeatures xsi:type="ecore:EReference" name="book"
lowerBound="1" eType="#//Book"/>
I update this field myself when I create new sections but getBook()
always returns null.
</pre>
<blockquote type="cite">
<pre wrap="">Aaron Digulla schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
I have a book which contains sections. Sections can contain sections.
For easier navigation, every section has a reference to the book.
Now, I'm running into problems: When I call setBook(), the
eContainerFeatureID is set to a negative value in
EcoreEList.inverseAdd() which causes getBook() to always return null:
public IBook getBook()
{
if (eContainerFeatureID != ModelPackage.SECTION__BOOK) return
null;
return (IBook)eContainer();
}
I understand that the code in inverseAdd() tries to flag the fact that
the book has no inverse mapping to section (because some sections are no
direct children of the book).
How do I fix this?
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------060907020805080201010608--
|
|
|
| Re: Recursive models [message #399318 is a reply to message #399296] |
Mon, 13 March 2006 15:13 |
| Eclipse User |
|
|
|
Ed Merks wrote:
> It seemed pretty clear from the generated code that
> "book" is a container reference which must be the opposite of a
> containment reference, but you aren't showing it having an opposite
> below.
ARGH... yeah, you're right, I mixed some things up while trying to
create the test case. Sorry.
Ok, second attempt.
I have this: Project contains Book contains lots of (recursive) Sections.
Containment is true for Project.books, so Book.project has Container ==
true.
When I trace the code, I get this:
- An EObjectContainmentEList for books is created with featureID 4
- Eventually inverseAdd() is called. hasNavigableInverse() is false.
- internalEObject.eInverseAdd() is called with the featureID -5
Now, the eContainerFeatureID of book is -5 (wrong) and the eContainer is
set to project (correct).
Here is the definition for books in Project:
<eStructuralFeatures xsi:type="ecore:EReference" name="books"
upperBound="-1" eType="#//Book" containment="true"/>
And project in Book looks like this:
<eStructuralFeatures xsi:type="ecore:EReference" name="project"
lowerBound="1" eType="#//Project" eOpposite="#//Project/books"/>
It somehow seems to be related to proxy resolution because the code
generated for Authors works:
Project.getBooks():
books = new EObjectContainmentEList.Resolving(Book.class, this,
ModelPackage.PROJECT__BOOKS);
Project.authors:
authors = new EObjectContainmentWithInverseEList(Author.class, this,
ModelPackage.PROJECT__AUTHORS, ModelPackage.AUTHOR__PROJECT);
As you can see, different classes are used to implement the lists.
Doesn't inverseAdd() work with proxies?
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/
|
|
|
| Re: Recursive models [message #399322 is a reply to message #399318] |
Tue, 14 March 2006 06:28 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------030804040005000300030203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Aaron,
Comments below.
Aaron Digulla wrote:
> Ed Merks wrote:
>
>
>> It seemed pretty clear from the generated code that
>> "book" is a container reference which must be the opposite of a
>> containment reference, but you aren't showing it having an opposite
>> below.
>>
>
> ARGH... yeah, you're right, I mixed some things up while trying to
> create the test case. Sorry.
>
> Ok, second attempt.
>
> I have this: Project contains Book contains lots of (recursive) Sections.
>
> Containment is true for Project.books, so Book.project has Container ==
> true.
>
> When I trace the code, I get this:
>
> - An EObjectContainmentEList for books is created with featureID 4
>
It should be an EObjectContainment*WithInverse*EList. The fact that it
isn't implies that it doesn't have an inverse in your Ecore model.
You're sure the eOpposite of each end points back to the other?
> - Eventually inverseAdd() is called. hasNavigableInverse() is false.
> - internalEObject.eInverseAdd() is called with the featureID -5
>
> Now, the eContainerFeatureID of book is -5 (wrong) and the eContainer is
> set to project (correct).
>
> Here is the definition for books in Project:
>
> <eStructuralFeatures xsi:type="ecore:EReference" name="books"
> upperBound="-1" eType="#//Book" containment="true"/>
>
> And project in Book looks like this:
>
> <eStructuralFeatures xsi:type="ecore:EReference" name="project"
> lowerBound="1" eType="#//Project" eOpposite="#//Project/books"/>
>
> It somehow seems to be related to proxy resolution because the code
> generated for Authors works:
>
> Project.getBooks():
>
> books = new EObjectContainmentEList.Resolving(Book.class, this,
> ModelPackage.PROJECT__BOOKS);
>
> Project.authors:
>
> authors = new EObjectContainmentWithInverseEList(Author.class, this,
> ModelPackage.PROJECT__AUTHORS, ModelPackage.AUTHOR__PROJECT);
>
> As you can see, different classes are used to implement the lists.
> Doesn't inverseAdd() work with proxies?
>
>
--------------030804040005000300030203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Aaron,<br>
<br>
Comments below.<br>
<br>
<br>
Aaron Digulla wrote:
<blockquote cite="middv4jtu$rrc$1@utils.eclipse.org" type="cite">
<pre wrap="">Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> It seemed pretty clear from the generated code that
"book" is a container reference which must be the opposite of a
containment reference, but you aren't showing it having an opposite
below.
</pre>
</blockquote>
<pre wrap=""><!---->
ARGH... yeah, you're right, I mixed some things up while trying to
create the test case. Sorry.
Ok, second attempt.
I have this: Project contains Book contains lots of (recursive) Sections.
Containment is true for Project.books, so Book.project has Container ==
true.
When I trace the code, I get this:
- An EObjectContainmentEList for books is created with featureID 4
</pre>
</blockquote>
It should be an EObjectContainment<b>WithInverse</b>EList. The fact
that it isn't implies that it doesn't have an inverse in your Ecore
model. You're sure the eOpposite of each end points back to the other?<br>
<blockquote cite="middv4jtu$rrc$1@utils.eclipse.org" type="cite">
<pre wrap="">- Eventually inverseAdd() is called. hasNavigableInverse() is false.
- internalEObject.eInverseAdd() is called with the featureID -5
Now, the eContainerFeatureID of book is -5 (wrong) and the eContainer is
set to project (correct).
Here is the definition for books in Project:
<eStructuralFeatures xsi:type="ecore:EReference" name="books"
upperBound="-1" eType="#//Book" containment="true"/>
And project in Book looks like this:
<eStructuralFeatures xsi:type="ecore:EReference" name="project"
lowerBound="1" eType="#//Project" eOpposite="#//Project/books"/>
It somehow seems to be related to proxy resolution because the code
generated for Authors works:
Project.getBooks():
books = new EObjectContainmentEList.Resolving(Book.class, this,
ModelPackage.PROJECT__BOOKS);
Project.authors:
authors = new EObjectContainmentWithInverseEList(Author.class, this,
ModelPackage.PROJECT__AUTHORS, ModelPackage.AUTHOR__PROJECT);
As you can see, different classes are used to implement the lists.
Doesn't inverseAdd() work with proxies?
</pre>
</blockquote>
<br>
</body>
</html>
--------------030804040005000300030203--
|
|
| |
| Re: EMF criticism (Was: Re: Recursive models) [message #399348 is a reply to message #399347] |
Tue, 14 March 2006 15:42 |
| Eclipse User |
|
|
|
Aaron,
I'm not sure how you set one end of the opposite but not the other; the
Ecore editor sets both at once. (It's called a Sample editor for a good
reason.)
I can't do much about your expectations other than to set them
straight. Given that the software, service, and support are all free,
you're certainly getting much more than you paid for.
What would you suggest be done when it comes to understanding how EMF
works? We have papers, articles, tutorials, and a book, but more is
always better so contributions of additional useful documentation is
more than welcome...
Aaron Digulla wrote:
> Ed,
>
>> Are the opposites set?
>
> Thanks, that was it, of course :-(
>
> I must admit that EMF is starting to irritate me. It works as it
> should but not as I expect it to. Even simple things cost a lot of
> time to track down, understand and fix.
>
> Even the questions here on the list show that something needs to be
> done when it comes to understanding how EMF works.
>
> Regards,
>
|
|
|
| Re: EMF criticism [message #399363 is a reply to message #399347] |
Wed, 15 March 2006 08:42 |
| Eclipse User |
|
|
|
Originally posted by: philipp.kutter.credit-suisse.com
Hi, Aron.
My own company develops all software since more than 3 years based on EMF
and at one of the largest Banks we use it since 18 months, and now
introduced it officially.
We never got special budget, and never had any additional time available.
EMF showed to be very easy to use, dead stable, always improving, and they
fixed problems within no time. And especially the news group answers where
always very useful.
Your negative comment surprises me a lot.
Philipp
|
|
|
Goto Forum:
Current Time: Sun Nov 09 17:29:41 EST 2025
Powered by FUDForum. Page generated in 0.25258 seconds |
Home