Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Teneo - I loose my EObject fields
| Teneo - I loose my EObject fields [message #63706] |
Tue, 05 December 2006 08:10  |
Eclipse User |
|
|
|
Originally posted by: mat.loo.gmail.com
Hi,
I have trouble when adding an EObject to a container (and I think in using
EMF with JPOX in a whole...).
When I perform my AddCommand, undo, redo, undo, redo... Everything works
fine (At this time, I do not use any Teneo facility, since my new EObject
was not stored in any database and only exists in my EMF model instance).
Then I undo and I save.
Then, when I redo, looking at my AddCommand.doRedo, I see my newly created
EObject has all its fields reseted ! (and then, when trying to to store to
the database raises an error because of Diagnosicts on required fields)
Any suggestion ?
Thx
Mat
|
|
|
| Re: Teneo - I loose my EObject fields [message #63775 is a reply to message #63706] |
Tue, 05 December 2006 13:54  |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi,
Are the fields already reset before the redo?
The save should not change the object itself, only for isMany features. The list implementation in
the isMany feature is replaced by a persistable list to support lazy loading. Primitive fields
should not be changed.
Can you debug to get more insight in what the redo does (where do the reseted/default values come from)?
gr. Martin
Mat Lo wrote:
> Hi,
>
> I have trouble when adding an EObject to a container (and I think in
> using EMF with JPOX in a whole...).
> When I perform my AddCommand, undo, redo, undo, redo... Everything works
> fine (At this time, I do not use any Teneo facility, since my new
> EObject was not stored in any database and only exists in my EMF model
> instance).
>
> Then I undo and I save.
>
> Then, when I redo, looking at my AddCommand.doRedo, I see my newly
> created EObject has all its fields reseted ! (and then, when trying to
> to store to the database raises an error because of Diagnosicts on
> required fields)
>
> Any suggestion ?
>
> Thx
>
> Mat
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Teneo - I loose my EObject fields [message #63868 is a reply to message #63775] |
Wed, 06 December 2006 07:23 |
| Eclipse User |
|
|
|
Originally posted by: mat.loo.gmail.com
> Hi,
>Hi
> Are the fields already reset before the redo?
Yes, I put my breakpoint just before the redo of AddCommand executes and
the field of my EObject are already deleted.
Note that the id (Object id, not the OID) is the same from the beginning
of the first Add and remains the same till it fields are reseted.
So, it is not another EObject that is created but really "mine", whose
fields are reseted.
> The save should not change the object itself, only for isMany features. The
list implementation in
> the isMany feature is replaced by a persistable list to support lazy
loading. Primitive fields
> should not be changed.
My feature is an EAttribute, so I guess nothing should interfere...
> Can you debug to get more insight in what the redo does (where do the
reseted/default values come from)?
I put a breakpoint in a (generated) setters of my EObject and code never
goes there. So I guess a "jdoSetxxx" method is called (only a thought !).
When I use the same code in XMI context, everything works great...
Maybe the problem comes from a bad configuration of Teneo ?
Is there any annotation I should put on my EAttributes (like oneToMany for
EReference for instance) ?
> gr. Martin
Thx
|
|
|
| Re: Teneo - I loose my EObject fields [message #63890 is a reply to message #63868] |
Wed, 06 December 2006 10:36 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Mat,
Can you debug some further (into the save action) to see what happens? I currently can not say where
this behavior is coming from.
gr. Martin
Mat Lo wrote:
>> Hi,
>> Hi
>
>> Are the fields already reset before the redo?
> Yes, I put my breakpoint just before the redo of AddCommand executes and
> the field of my EObject are already deleted.
> Note that the id (Object id, not the OID) is the same from the beginning
> of the first Add and remains the same till it fields are reseted.
> So, it is not another EObject that is created but really "mine", whose
> fields are reseted.
>
>> The save should not change the object itself, only for isMany
>> features. The
> list implementation in
>> the isMany feature is replaced by a persistable list to support lazy
> loading. Primitive fields
>> should not be changed.
> My feature is an EAttribute, so I guess nothing should interfere...
>
>> Can you debug to get more insight in what the redo does (where do the
> reseted/default values come from)?
> I put a breakpoint in a (generated) setters of my EObject and code never
> goes there. So I guess a "jdoSetxxx" method is called (only a thought !).
>
> When I use the same code in XMI context, everything works great...
> Maybe the problem comes from a bad configuration of Teneo ?
> Is there any annotation I should put on my EAttributes (like oneToMany
> for EReference for instance) ?
>
>> gr. Martin
> Thx
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Teneo - I loose my EObject fields [message #64288 is a reply to message #63890] |
Mon, 11 December 2006 16:53 |
| Eclipse User |
|
|
|
Originally posted by: mat.loo.gmail.com
Hi,
I don't know if it is linked to my problem, but I found the following
behaviour that surprises me.
In EContainerRepairControl (of org.eclipse.emf.teneo), the repair
functionnality seems to be strange.
Some times, I arrive in the return of the following repair method:
if (!childClass.isAssignableFrom(child.getClass())) {
return; // not handled by this container
}
In this case, I come from repair where :
for (int i = 0; i < repairList.size(); i++) {
RepairControl repairControl = (RepairControl) repairList.get(i);
if (repairControl.getFeatureID() == correctedFeatureID) {
repairControl.repair((InternalEObject) owner, (InternalEObject) child);
return;
}
}
But, in this case, I have correctedFeatureID ==
repairControl.getFeatureID() (obviously !) but it seems to be false
because we are comparing the id of the feature to the id of the opposite
feature in the opposite object. And that's why, some times, when a feature
is a TwoWayContainer (that is when the EReference is a container AND has
an eOpposite) the first repair returns because the expected child class is
not the wanted (!childClass.isAssignableFrom(child.getClass())).
To me, correctedFeatureID should not be initialised like this :
correctedFeatureID = ((EReference) estruct).getEOpposite().getFeatureID()
but like this :
correctedFeatureID = ((EReference) estruct).getFeatureID()
I guess this is not the "real good" solution but I show it to make myself
as clear as possible.
What do you think of this ?
thx
|
|
|
| Re: Teneo - I loose my EObject fields [message #64311 is a reply to message #64288] |
Wed, 13 December 2006 08:35 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Mat,
The correctedFeatureID should be the id of the feature which is in the contained object refering to
the container. For 2-way container the repairlist is built using this constructor:
private static class TwoWayContainer extends RepairControl {
/** Constructor */
TwoWayContainer(EReference containerReference, EReference toContainer) {
super(containerReference, toContainer.getFeatureID());
}
}
The feature id is the feature pointing to the container, the repair method is called with the
container feature and to get the correct repair action the featureid of the other side needs to be
determined. So afaics this is correct.
However, what I don't understand directly is why it returns here:
> if (!childClass.isAssignableFrom(child.getClass())) {
> return; // not handled by this container
> }
Can you debug to see what the childClass and child classes are?
gr. Martin
Mat Lo wrote:
> Hi,
>
> I don't know if it is linked to my problem, but I found the following
> behaviour that surprises me.
>
> In EContainerRepairControl (of org.eclipse.emf.teneo), the repair
> functionnality seems to be strange.
>
> Some times, I arrive in the return of the following repair method:
> if (!childClass.isAssignableFrom(child.getClass())) {
> return; // not handled by this container
> }
>
> In this case, I come from repair where :
> for (int i = 0; i < repairList.size(); i++) {
> RepairControl repairControl = (RepairControl)
> repairList.get(i);
> if (repairControl.getFeatureID() == correctedFeatureID) {
> repairControl.repair((InternalEObject) owner,
> (InternalEObject) child);
> return;
> }
> }
>
> But, in this case, I have correctedFeatureID ==
> repairControl.getFeatureID() (obviously !) but it seems to be false
> because we are comparing the id of the feature to the id of the opposite
> feature in the opposite object. And that's why, some times, when a
> feature is a TwoWayContainer (that is when the EReference is a container
> AND has an eOpposite) the first repair returns because the expected
> child class is not the wanted
> (!childClass.isAssignableFrom(child.getClass())).
>
> To me, correctedFeatureID should not be initialised like this :
> correctedFeatureID = ((EReference) estruct).getEOpposite().getFeatureID()
> but like this :
> correctedFeatureID = ((EReference) estruct).getFeatureID()
>
> I guess this is not the "real good" solution but I show it to make
> myself as clear as possible.
>
> What do you think of this ?
>
> thx
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Teneo - I loose my EObject fields [message #64566 is a reply to message #64311] |
Fri, 15 December 2006 10:17 |
| Eclipse User |
|
|
|
Originally posted by: mat.loo.gmail.com
I think I have it !
All I said about eOpposite id seems to be wrong... (I don't know why I
found this but, anyway...).
The point seems to be:
if by any chance, I have, in my Ecore mode, 2 contained EObjects that have
the same id for the feature that links them to their container, sometimes
it works, sometimes not depending on the order the repairList is built.
For example :
Container
|_Child1
|_Child2
Child1
|_xxx
|_xxx
|_xxx
|_Container
Child2
|_xxx
|_xxx
|_xxx
|_Container
The fact that the feature to the Container is 3 in both cases make the
repair lose itself. And then, depending on the repairList, sometimes, when
trying to repair the link Container->Child1, it may arrive in the final
Repair with class of Child2.
For me, the solution is the move some code like this :
for (int i = 0; i < repairList.size(); i++) {
RepairControl repairControl = (RepairControl)
repairList.get(i);
if (repairControl.getFeatureID() == correctedFeatureID) {
/////CHANGE && repairControl.childClass.isAssignableFrom(child.getClass())
repairControl.repair((InternalEObject) owner,
(InternalEObject) child);
return;
}
}
And then, in repairControl.repair the
childClass.isAssignableFrom(child.getClass()) is not needed anymore
The test has to be done earlier because otherwise, the call to
repairControl.repair may return doing nothing and the for loop always
returns after repairControl.repair.
What do you think ?
|
|
|
| Re: Teneo - I loose my EObject fields [message #64799 is a reply to message #64566] |
Mon, 18 December 2006 21:20 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Mat,
My reply took a while because of busy work schedules.
Thanks, this seems to be the issue, this is/was for sure a very hidden issue.
I have changed it as you proposed and committed it. This will be in the next release (next week).
gr. Martin
Mat Lo wrote:
> I think I have it !
>
> All I said about eOpposite id seems to be wrong... (I don't know why I
> found this but, anyway...).
>
> The point seems to be:
> if by any chance, I have, in my Ecore mode, 2 contained EObjects that
> have the same id for the feature that links them to their container,
> sometimes it works, sometimes not depending on the order the repairList
> is built.
>
> For example :
>
> Container
> |_Child1
> |_Child2
>
> Child1
> |_xxx
> |_xxx
> |_xxx
> |_Container
>
> Child2
> |_xxx
> |_xxx
> |_xxx
> |_Container
>
> The fact that the feature to the Container is 3 in both cases make the
> repair lose itself. And then, depending on the repairList, sometimes,
> when trying to repair the link Container->Child1, it may arrive in the
> final Repair with class of Child2.
>
> For me, the solution is the move some code like this :
>
> for (int i = 0; i < repairList.size(); i++) {
> RepairControl repairControl = (RepairControl)
> repairList.get(i);
> if (repairControl.getFeatureID() == correctedFeatureID) {
>
> /////CHANGE && repairControl.childClass.isAssignableFrom(child.getClass())
>
> repairControl.repair((InternalEObject) owner,
> (InternalEObject) child);
> return;
> }
> }
>
> And then, in repairControl.repair the
> childClass.isAssignableFrom(child.getClass()) is not needed anymore
>
> The test has to be done earlier because otherwise, the call to
> repairControl.repair may return doing nothing and the for loop always
> returns after repairControl.repair.
>
> What do you think ?
>
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
| |
| Re: Teneo - I loose my EObject fields [message #596539 is a reply to message #63706] |
Tue, 05 December 2006 13:54 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi,
Are the fields already reset before the redo?
The save should not change the object itself, only for isMany features. The list implementation in
the isMany feature is replaced by a persistable list to support lazy loading. Primitive fields
should not be changed.
Can you debug to get more insight in what the redo does (where do the reseted/default values come from)?
gr. Martin
Mat Lo wrote:
> Hi,
>
> I have trouble when adding an EObject to a container (and I think in
> using EMF with JPOX in a whole...).
> When I perform my AddCommand, undo, redo, undo, redo... Everything works
> fine (At this time, I do not use any Teneo facility, since my new
> EObject was not stored in any database and only exists in my EMF model
> instance).
>
> Then I undo and I save.
>
> Then, when I redo, looking at my AddCommand.doRedo, I see my newly
> created EObject has all its fields reseted ! (and then, when trying to
> to store to the database raises an error because of Diagnosicts on
> required fields)
>
> Any suggestion ?
>
> Thx
>
> Mat
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Teneo - I loose my EObject fields [message #596588 is a reply to message #63775] |
Wed, 06 December 2006 07:23 |
| Eclipse User |
|
|
|
Originally posted by: mat.loo.gmail.com
> Hi,
>Hi
> Are the fields already reset before the redo?
Yes, I put my breakpoint just before the redo of AddCommand executes and
the field of my EObject are already deleted.
Note that the id (Object id, not the OID) is the same from the beginning
of the first Add and remains the same till it fields are reseted.
So, it is not another EObject that is created but really "mine", whose
fields are reseted.
> The save should not change the object itself, only for isMany features. The
list implementation in
> the isMany feature is replaced by a persistable list to support lazy
loading. Primitive fields
> should not be changed.
My feature is an EAttribute, so I guess nothing should interfere...
> Can you debug to get more insight in what the redo does (where do the
reseted/default values come from)?
I put a breakpoint in a (generated) setters of my EObject and code never
goes there. So I guess a "jdoSetxxx" method is called (only a thought !).
When I use the same code in XMI context, everything works great...
Maybe the problem comes from a bad configuration of Teneo ?
Is there any annotation I should put on my EAttributes (like oneToMany for
EReference for instance) ?
> gr. Martin
Thx
|
|
|
| Re: Teneo - I loose my EObject fields [message #596596 is a reply to message #63868] |
Wed, 06 December 2006 10:36 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Mat,
Can you debug some further (into the save action) to see what happens? I currently can not say where
this behavior is coming from.
gr. Martin
Mat Lo wrote:
>> Hi,
>> Hi
>
>> Are the fields already reset before the redo?
> Yes, I put my breakpoint just before the redo of AddCommand executes and
> the field of my EObject are already deleted.
> Note that the id (Object id, not the OID) is the same from the beginning
> of the first Add and remains the same till it fields are reseted.
> So, it is not another EObject that is created but really "mine", whose
> fields are reseted.
>
>> The save should not change the object itself, only for isMany
>> features. The
> list implementation in
>> the isMany feature is replaced by a persistable list to support lazy
> loading. Primitive fields
>> should not be changed.
> My feature is an EAttribute, so I guess nothing should interfere...
>
>> Can you debug to get more insight in what the redo does (where do the
> reseted/default values come from)?
> I put a breakpoint in a (generated) setters of my EObject and code never
> goes there. So I guess a "jdoSetxxx" method is called (only a thought !).
>
> When I use the same code in XMI context, everything works great...
> Maybe the problem comes from a bad configuration of Teneo ?
> Is there any annotation I should put on my EAttributes (like oneToMany
> for EReference for instance) ?
>
>> gr. Martin
> Thx
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Teneo - I loose my EObject fields [message #596770 is a reply to message #63890] |
Mon, 11 December 2006 16:53 |
| Eclipse User |
|
|
|
Originally posted by: mat.loo.gmail.com
Hi,
I don't know if it is linked to my problem, but I found the following
behaviour that surprises me.
In EContainerRepairControl (of org.eclipse.emf.teneo), the repair
functionnality seems to be strange.
Some times, I arrive in the return of the following repair method:
if (!childClass.isAssignableFrom(child.getClass())) {
return; // not handled by this container
}
In this case, I come from repair where :
for (int i = 0; i < repairList.size(); i++) {
RepairControl repairControl = (RepairControl) repairList.get(i);
if (repairControl.getFeatureID() == correctedFeatureID) {
repairControl.repair((InternalEObject) owner, (InternalEObject) child);
return;
}
}
But, in this case, I have correctedFeatureID ==
repairControl.getFeatureID() (obviously !) but it seems to be false
because we are comparing the id of the feature to the id of the opposite
feature in the opposite object. And that's why, some times, when a feature
is a TwoWayContainer (that is when the EReference is a container AND has
an eOpposite) the first repair returns because the expected child class is
not the wanted (!childClass.isAssignableFrom(child.getClass())).
To me, correctedFeatureID should not be initialised like this :
correctedFeatureID = ((EReference) estruct).getEOpposite().getFeatureID()
but like this :
correctedFeatureID = ((EReference) estruct).getFeatureID()
I guess this is not the "real good" solution but I show it to make myself
as clear as possible.
What do you think of this ?
thx
|
|
|
| Re: Teneo - I loose my EObject fields [message #596778 is a reply to message #64288] |
Wed, 13 December 2006 08:35 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Mat,
The correctedFeatureID should be the id of the feature which is in the contained object refering to
the container. For 2-way container the repairlist is built using this constructor:
private static class TwoWayContainer extends RepairControl {
/** Constructor */
TwoWayContainer(EReference containerReference, EReference toContainer) {
super(containerReference, toContainer.getFeatureID());
}
}
The feature id is the feature pointing to the container, the repair method is called with the
container feature and to get the correct repair action the featureid of the other side needs to be
determined. So afaics this is correct.
However, what I don't understand directly is why it returns here:
> if (!childClass.isAssignableFrom(child.getClass())) {
> return; // not handled by this container
> }
Can you debug to see what the childClass and child classes are?
gr. Martin
Mat Lo wrote:
> Hi,
>
> I don't know if it is linked to my problem, but I found the following
> behaviour that surprises me.
>
> In EContainerRepairControl (of org.eclipse.emf.teneo), the repair
> functionnality seems to be strange.
>
> Some times, I arrive in the return of the following repair method:
> if (!childClass.isAssignableFrom(child.getClass())) {
> return; // not handled by this container
> }
>
> In this case, I come from repair where :
> for (int i = 0; i < repairList.size(); i++) {
> RepairControl repairControl = (RepairControl)
> repairList.get(i);
> if (repairControl.getFeatureID() == correctedFeatureID) {
> repairControl.repair((InternalEObject) owner,
> (InternalEObject) child);
> return;
> }
> }
>
> But, in this case, I have correctedFeatureID ==
> repairControl.getFeatureID() (obviously !) but it seems to be false
> because we are comparing the id of the feature to the id of the opposite
> feature in the opposite object. And that's why, some times, when a
> feature is a TwoWayContainer (that is when the EReference is a container
> AND has an eOpposite) the first repair returns because the expected
> child class is not the wanted
> (!childClass.isAssignableFrom(child.getClass())).
>
> To me, correctedFeatureID should not be initialised like this :
> correctedFeatureID = ((EReference) estruct).getEOpposite().getFeatureID()
> but like this :
> correctedFeatureID = ((EReference) estruct).getFeatureID()
>
> I guess this is not the "real good" solution but I show it to make
> myself as clear as possible.
>
> What do you think of this ?
>
> thx
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Teneo - I loose my EObject fields [message #596931 is a reply to message #64311] |
Fri, 15 December 2006 10:17 |
| Eclipse User |
|
|
|
Originally posted by: mat.loo.gmail.com
I think I have it !
All I said about eOpposite id seems to be wrong... (I don't know why I
found this but, anyway...).
The point seems to be:
if by any chance, I have, in my Ecore mode, 2 contained EObjects that have
the same id for the feature that links them to their container, sometimes
it works, sometimes not depending on the order the repairList is built.
For example :
Container
|_Child1
|_Child2
Child1
|_xxx
|_xxx
|_xxx
|_Container
Child2
|_xxx
|_xxx
|_xxx
|_Container
The fact that the feature to the Container is 3 in both cases make the
repair lose itself. And then, depending on the repairList, sometimes, when
trying to repair the link Container->Child1, it may arrive in the final
Repair with class of Child2.
For me, the solution is the move some code like this :
for (int i = 0; i < repairList.size(); i++) {
RepairControl repairControl = (RepairControl)
repairList.get(i);
if (repairControl.getFeatureID() == correctedFeatureID) {
/////CHANGE && repairControl.childClass.isAssignableFrom(child.getClass())
repairControl.repair((InternalEObject) owner,
(InternalEObject) child);
return;
}
}
And then, in repairControl.repair the
childClass.isAssignableFrom(child.getClass()) is not needed anymore
The test has to be done earlier because otherwise, the call to
repairControl.repair may return doing nothing and the for loop always
returns after repairControl.repair.
What do you think ?
|
|
|
| Re: Teneo - I loose my EObject fields [message #597059 is a reply to message #64566] |
Mon, 18 December 2006 21:20 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Mat,
My reply took a while because of busy work schedules.
Thanks, this seems to be the issue, this is/was for sure a very hidden issue.
I have changed it as you proposed and committed it. This will be in the next release (next week).
gr. Martin
Mat Lo wrote:
> I think I have it !
>
> All I said about eOpposite id seems to be wrong... (I don't know why I
> found this but, anyway...).
>
> The point seems to be:
> if by any chance, I have, in my Ecore mode, 2 contained EObjects that
> have the same id for the feature that links them to their container,
> sometimes it works, sometimes not depending on the order the repairList
> is built.
>
> For example :
>
> Container
> |_Child1
> |_Child2
>
> Child1
> |_xxx
> |_xxx
> |_xxx
> |_Container
>
> Child2
> |_xxx
> |_xxx
> |_xxx
> |_Container
>
> The fact that the feature to the Container is 3 in both cases make the
> repair lose itself. And then, depending on the repairList, sometimes,
> when trying to repair the link Container->Child1, it may arrive in the
> final Repair with class of Child2.
>
> For me, the solution is the move some code like this :
>
> for (int i = 0; i < repairList.size(); i++) {
> RepairControl repairControl = (RepairControl)
> repairList.get(i);
> if (repairControl.getFeatureID() == correctedFeatureID) {
>
> /////CHANGE && repairControl.childClass.isAssignableFrom(child.getClass())
>
> repairControl.repair((InternalEObject) owner,
> (InternalEObject) child);
> return;
> }
> }
>
> And then, in repairControl.repair the
> childClass.isAssignableFrom(child.getClass()) is not needed anymore
>
> The test has to be done earlier because otherwise, the call to
> repairControl.repair may return doing nothing and the for loop always
> returns after repairControl.repair.
>
> What do you think ?
>
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 12:33:32 GMT 2024
Powered by FUDForum. Page generated in 0.02852 seconds |
] 
Search
Help
Register
Login
Home
