Home » Modeling » EMF » Unexpected Behavior in Generated Code
| Unexpected Behavior in Generated Code [message #421237] |
Fri, 01 August 2008 15:03  |
 Geoffry Roberts
Messages: 71
Registered: July 2009 |
Member |
|
|
All,
I'm posting this mostly because I'd like to understand EMF better, I'm
finding some little gotchas here and there in the way the generated code
works that are surprising to me and wind up cleaning my clock. I'm
seeking either a work around, or better yet, a more excellent ways. In
everything I've read, including books I have purchased, I find more
mention of these things.
Apologies in advance if some of this is common knowledge and I should just
know better.
I have been using EMF in my current project. I generate code from xsd
and for the most part my experience has been good. I have, however,
noticed this certain behavior oddities.
EList behavior:
I have a situation where I to make modifications on certain objects
selected at random from an EList. I have noticed each time I make a
section: myElist.get(randomInt); the size of my EList is reduced by one.
My Elist then shrinks and shrinks until an out of bounds exception is
thrown. This behavior differs from the commonly used
java.util.ArrayList. Elist apparently removes the object when the
get(rand) is called. Why? and more importantly, is there a work around?
My present work around is to add all to and ArrayList, do my random
business, then replace the contents of my EList from the ArrayList. Seems
like an inordinate amount of data shuffling.
Many to One behavior:
I have a modeled a number of Persons and a number of Diseases. Any person
may or may not be infected with any disease. When I setDisease(disease)
the first person then attempt the same thing on the second, EMF removes
the disease from the first person. I actually stepped through the code on
this. I can do this kind of Many to One thing is regular java why does
EMF do this to me? Is there a tweak I can make to my xsd to mitigate this?
|
|
|
| Re: Unexpected Behavior in Generated Code [message #421242 is a reply to message #421237] |
Fri, 01 August 2008 15:40  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Geoffry,
Comments below.
Geoffry Roberts wrote:
> All,
>
> I'm posting this mostly because I'd like to understand EMF better, I'm
> finding some little gotchas here and there in the way the generated
> code works that are surprising to me and wind up cleaning my clock.
> I'm seeking either a work around, or better yet, a more excellent
> ways. In everything I've read, including books I have purchased, I
> find more mention of these things.
>
> Apologies in advance if some of this is common knowledge and I should
> just know better.
>
> I have been using EMF in my current project. I generate code from
> xsd and for the most part my experience has been good. I have,
> however, noticed this certain behavior oddities.
>
> EList behavior:
>
> I have a situation where I to make modifications on certain objects
> selected at random from an EList. I have noticed each time I make a
> section: myElist.get(randomInt); the size of my EList is reduced by
> one. My Elist then shrinks and shrinks until an out of bounds
> exception is thrown. This behavior differs from the commonly used
> java.util.ArrayList. Elist apparently removes the object when the
> get(rand) is called. Why? and more importantly, is there a work
> around? My present work around is to add all to and ArrayList, do my
> random business, then replace the contents of my EList from the
> ArrayList. Seems like an inordinate amount of data shuffling.
It sounds more likely that you are taking the objects in that list and
adding them to some other list. And not just to some other "plain old"
list but rather another containment list. I.e., you are likely seeing
the result of bidirectional updates that ensure that each EObject has
only one eContainer. It's actually no different from DOM where adding
an element of a child of some other element will change the getParent()
and will remove it from the previous parent.
Definitely calling get will not change the size of the list. That will
only happen if you do something with the object you've fetched that
would cause it to be removed, like adding it to the containment EList of
some other container.
>
> Many to One behavior:
>
> I have a modeled a number of Persons and a number of Diseases. Any
> person may or may not be infected with any disease.
Gross. :-P
> When I setDisease(disease) the first person then attempt the same
> thing on the second, EMF removes the disease from the first person.
More bidirectional update issues...
> I actually stepped through the code on this. I can do this kind of
> Many to One thing is regular java why does EMF do this to me? Is
> there a tweak I can make to my xsd to mitigate this?
I really need to see the model to give better concrete advice. It sounds
likely that you've modeled this in an inappropriate way. Keep in mind
that an object can have at most one eContainer and it knows which
eContainmentFeature of that container contains it. Adding that object
to some other list will cause it to be removed so it seems unlikely
you'd want to use containment references to implement this
person/disease thing. It's more likely to be like the writers/books
non-containment reference from our library example.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Unexpected Behavior in Generated Code [message #421246 is a reply to message #421242] |
Fri, 01 August 2008 16:44 |
Geoffry Roberts
Messages: 71
Registered: July 2009 |
Member |
|
|
Thanks for the quick response.
I think I am beginning to understand. Lets see if I really do.
In the case of the Person/Disease relationship, I have modeled it so that
a person can have more than one disease. This results in an EList in the
generated code so the call might be: epiPerson.getDisease(), which returns
s Elist<Disease>. If I understand you correctly, adding a given disease
object to more than one epiPerson is effectively adding it to more than
one container.
When I model:
<xs:element name="disease" maxOccurs="unbounded" type="Disease">
...an EList is generated and therein lies the rub.
How else, then, can I model some poor soul as having say hepatitis, acid
reflux, and influenza all at once?
On to the get(rand) issue:
for (i = 0; i < population; i++) {
int rand = mtf.getNextRandAsInteger(population);
EpiPerson epiPerson = epiPersons.get(rand);
epiPerson.setPersonState(state);
}
In the above, "state" is the disease state of the person. It contains
various Elists of objects. When I do my get(rand) and then
setPersonState(state), I'll bet this bidirectional business you've
pointed out is causing the epiPerson to be removed from the epiPersons
EList. Correct?
|
|
|
| Re: Unexpected Behavior in Generated Code [message #421250 is a reply to message #421246] |
Fri, 01 August 2008 16:53 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000300050603020801090309
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Geoffry,
Comments below.
Geoffry roberts wrote:
> Thanks for the quick response.
>
> I think I am beginning to understand. Lets see if I really do.
>
> In the case of the Person/Disease relationship, I have modeled it so
> that a person can have more than one disease. This results in an
> EList in the generated code so the call might be:
> epiPerson.getDisease(), which returns s Elist<Disease>. If I
> understand you correctly, adding a given disease object to more than
> one epiPerson is effectively adding it to more than one container.
Yep, and that's not allowed so EMF handily keeps things consistent just
like DOM does.
> When I model:
> <xs:element name="disease" maxOccurs="unbounded" type="Disease">
> ..an EList is generated and therein lies the rub.
> How else, then, can I model some poor soul as having say hepatitis,
> acid reflux, and influenza all at once?
You should look at the library example which shows yow to use anyURI to
define strongly-typed non-containment references:
<xsd:complexType name="Book">
<xsd:sequence>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="pages" type="xsd:int"/>
<xsd:element name="category" type="lib:BookCategory"/>
<xsd:element *ecore:opposite="books"
ecore:reference="lib:Writer"* name="author" type="xsd:anyURI"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Writer">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element *ecore:reference="lib:Book"*
maxOccurs="unbounded" minOccurs="0" name="books" type="xsd:anyURI"/>
</xsd:sequence>
</xsd:complexType>
>
> On to the get(rand) issue:
>
> for (i = 0; i < population; i++) {
> int rand = mtf.getNextRandAsInteger(population);
> EpiPerson epiPerson = epiPersons.get(rand);
> epiPerson.setPersonState(state);
> }
>
> In the above, "state" is the disease state of the person. It contains
> various Elists of objects. When I do my get(rand) and then
> setPersonState(state), I'll bet this bidirectional business you've
> pointed out is causing the epiPerson to be removed from the epiPersons
> EList. Correct?
Exactly. I think you want to model this in which a way that Diseases
and Persons are contained by some common parent (as Book and Writer are
in Library), and then you'll have and n-m relation between them. After
all a person can have many diseases and any one disease can afflict many
people. It's also possible to put each Disease and Person in a separate
resource, or even all at the root of a single resource, but the latter
wouldn't correspond to any actual schema and hence would need to use an
XMIResourceImpl.
--------------000300050603020801090309
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">
Geoffry,<br>
<br>
Comments below.<br>
<br>
Geoffry roberts wrote:
<blockquote
cite="mid:e857da507610df7ccb0d71461f0bfd07$1@www.eclipse.org"
type="cite">Thanks for the quick response.
<br>
<br>
I think I am beginning to understand.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 27 04:55:50 GMT 2024
Powered by FUDForum. Page generated in 0.03315 seconds |
] 
Search
Help
Register
Login
Home
