[CDO] eIsSet is ko for eOpposite structural feature ? [message #1454866] |
Tue, 28 October 2014 21:18 |
Stephane fournier Messages: 340 Registered: July 2009 |
Senior Member |
|
|
Hi,
When using EcoreUtil.equals(cdoObjectInstance1, cdoObjectInstance2) in a CDO context (native cdo objects), I get a false where I was supposed to get true.
Hence, I debugged the stuff to understand why the answer is false.
cdoObjectInstance1 is an object loaded from an XML file as transient object.
cdoObjectInstance2 is the same object stored (clean state) in a memory CDO Store.
After debugging, I found out the comparison returns false due to a difference regarding one structural feature that is set as an eOpposite of another one.
In cdoObjectInstance1 (the one loaded from an xml file), eIsSet(feature) returns true and that's correct whereas cdoObjectInstance2 returns false for the same feature ==> EcoreUtil stops and returns false.
If I run cdoObjectInstance2.eGet(feature) ( or if call the explicit method), I get my pointed object.
Hence, I don't understand why the eIsSet() is returning false instead of true.
I made a try with the legacy mode, where the issue does not exist, but for other reasons I'd prefer using the native mode.
Does anyone have any ideas ?
I'm using a Modeling platform : Kepler 4.3.2. I do not test with the Luna SR1.
To workaround the issue, I will override the EcoreUtil code to check if the eOpposite feature is really set in calling eGet(feature) != null instead of eIsSet(feature).
Stephane.
|
|
|
Re: [CDO] eIsSet is ko for eOpposite structural feature ? [message #1471452 is a reply to message #1454866] |
Thu, 13 November 2014 04:57 |
|
Hi Stephane,
IIRC, Kepler came with CDO 4.2, which is not maintained anymore. Even though your problem seems like a bug in CDO (most
likely in the way how the model data is converted/used between the EObject and the CDORevision) it's important that you
verify that that problem exists in at least CDO 4.3 (better 4.4/master). Nobody will work on CDO 4.2 anymore and there
are no build jobs for that version anymore.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 28.10.2014 um 22:18 schrieb Stephane Fournier:
> Hi,
>
> When using EcoreUtil.equals(cdoObjectInstance1, cdoObjectInstance2) in a CDO context (native cdo objects), I get a
> false where I was supposed to get true.
> Hence, I debugged the stuff to understand why the answer is false.
>
> cdoObjectInstance1 is an object loaded from an XML file as transient object.
> cdoObjectInstance2 is the same object stored (clean state) in a memory CDO Store.
>
> After debugging, I found out the comparison returns false due to a difference regarding one structural feature that is
> set as an eOpposite of another one.
>
> In cdoObjectInstance1 (the one loaded from an xml file), eIsSet(feature) returns true and that's correct whereas
> cdoObjectInstance2 returns false for the same feature ==> EcoreUtil stops and returns false.
>
> If I run cdoObjectInstance2.eGet(feature) ( or if call the explicit method), I get my pointed object.
>
> Hence, I don't understand why the eIsSet() is returning false instead of true.
>
> I made a try with the legacy mode, where the issue does not exist, but for other reasons I'd prefer using the native
> mode.
>
> Does anyone have any ideas ?
>
> I'm using a Modeling platform : Kepler 4.3.2. I do not test with the Luna SR1.
>
> To workaround the issue, I will override the EcoreUtil code to check if the eOpposite feature is really set in calling
> eGet(feature) != null instead of eIsSet(feature).
>
> Stephane.
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Powered by
FUDForum. Page generated in 0.01813 seconds