Home » Modeling » EMF » [CDO] CDOObject equality.
| [CDO] CDOObject equality. [message #1061130] |
Thu, 30 May 2013 03:36  |
Eclipse User |
|
|
|
Hi,
I just experienced something interesting today.
Suppose
CDOObject object .....
CDOObject objectFromT1 = transaction1.getObject(object.cdoID);
CDOObject objectFromT2 = transaction2.getObject(object.cdoID);
objectFromT1.equals(objetFromT2) => false
hehe go figure...
rgds Christophe
|
|
| |
| Re: [CDO] CDOObject equality. [message #1061196 is a reply to message #1061184] |
Thu, 30 May 2013 09:30  |
| Eclipse User |
|
|
|
On 30-05-13 14:50, Christian W. Damus wrote:
> Hi, Christophe,
>
> This is consistent with EMF's contract for EObject::equals(), that it is
> reference identity. This is no different than loading the "same" object
> from the "same" XML resource (file) in two different ResourceSets.
>
> Is it a problem?
>
Hi Christian,
It's not a problem, if you are aware of this.
One could argue that when persisted in the CDO Repo or XML file it's
really one single "thing", there aren't any two of these "things", of
course when de-serialized as Java Object, they could be considered
different because a ResourceSet or CDO Transaction is a 'representation'
of the thing in a certain condition, and each can be manipulated and
hold state (In the CDO case).
From a natural world perspective it doesn't feel right, but as said,
it's not a problem when you know it. I just needed to write an equality
method which compares the CDOID or URIFragments and conclude that they
are really the same 'thing', regardless of what EMF might think :P
Cheers Christophe
> cW
>
>
> On 2013-05-30 07:36:04 +0000, Christophe Bouhier said:
>
>> Hi,
>>
>> I just experienced something interesting today.
>>
>> Suppose
>>
>> CDOObject object .....
>>
>> CDOObject objectFromT1 = transaction1.getObject(object.cdoID);
>> CDOObject objectFromT2 = transaction2.getObject(object.cdoID);
>>
>> objectFromT1.equals(objetFromT2) => false
>>
>> hehe go figure...
>>
>> rgds Christophe
>
>
|
|
|
| Re: [CDO] CDOObject equality. [message #1061202 is a reply to message #1061196] |
Thu, 30 May 2013 09:54 |
| Eclipse User |
|
|
|
Christophe,
Comments below.
On 30/05/2013 3:30 PM, Christophe Bouhier wrote:
> On 30-05-13 14:50, Christian W. Damus wrote:
>> Hi, Christophe,
>>
>> This is consistent with EMF's contract for EObject::equals(), that it is
>> reference identity. This is no different than loading the "same" object
>> from the "same" XML resource (file) in two different ResourceSets.
>>
>> Is it a problem?
>>
> Hi Christian,
>
> It's not a problem, if you are aware of this.
>
> One could argue that when persisted in the CDO Repo or XML file it's
> really one single "thing", there aren't any two of these "things", of
> course when de-serialized as Java Object, they could be considered
> different because a ResourceSet or CDO Transaction is a
> 'representation' of the thing in a certain condition, and each can be
> manipulated and hold state (In the CDO case).
Yes and until a transaction is committed you have a local representation
of that thing. And each transaction has a different one that each can
modify differently (leading to conflicts on commit).
>
> From a natural world perspective it doesn't feel right, but as said,
> it's not a problem when you know it.
I think it's necessarily this way...
> I just needed to write an equality
> method which compares the CDOID or URIFragments and conclude that they
> are really the same 'thing', regardless of what EMF might think :P
Even if they represent the same object, their states can be different,
so are they really equal then? In what context would you need this kind
of testing?
>
> Cheers Christophe
>
>
>> cW
>>
>>
>> On 2013-05-30 07:36:04 +0000, Christophe Bouhier said:
>>
>>> Hi,
>>>
>>> I just experienced something interesting today.
>>>
>>> Suppose
>>>
>>> CDOObject object .....
>>>
>>> CDOObject objectFromT1 = transaction1.getObject(object.cdoID);
>>> CDOObject objectFromT2 = transaction2.getObject(object.cdoID);
>>>
>>> objectFromT1.equals(objetFromT2) => false
>>>
>>> hehe go figure...
>>>
>>> rgds Christophe
>>
>>
>
|
|
|
| Re: [CDO] CDOObject equality. [message #1061213 is a reply to message #1061202] |
Thu, 30 May 2013 10:35 |
| Eclipse User |
|
|
|
On 30-05-13 15:54, Ed Merks wrote:
> Christophe,
>
> Comments below.
>
> On 30/05/2013 3:30 PM, Christophe Bouhier wrote:
>> On 30-05-13 14:50, Christian W. Damus wrote:
>>> Hi, Christophe,
>>>
>>> This is consistent with EMF's contract for EObject::equals(), that it is
>>> reference identity. This is no different than loading the "same" object
>>> from the "same" XML resource (file) in two different ResourceSets.
>>>
>>> Is it a problem?
>>>
>> Hi Christian,
>>
>> It's not a problem, if you are aware of this.
>>
>> One could argue that when persisted in the CDO Repo or XML file it's
>> really one single "thing", there aren't any two of these "things", of
>> course when de-serialized as Java Object, they could be considered
>> different because a ResourceSet or CDO Transaction is a
>> 'representation' of the thing in a certain condition, and each can be
>> manipulated and hold state (In the CDO case).
> Yes and until a transaction is committed you have a local representation
> of that thing. And each transaction has a different one that each can
> modify differently (leading to conflicts on commit).
>>
>> From a natural world perspective it doesn't feel right, but as said,
>> it's not a problem when you know it.
> I think it's necessarily this way...
>> I just needed to write an equality
>> method which compares the CDOID or URIFragments and conclude that they
>> are really the same 'thing', regardless of what EMF might think :P
> Even if they represent the same object, their states can be different,
> so are they really equal then?
I think they are the same but in a different lifecycle state, but that's
really my context, someone else might say they are not. Having said that
in my case, I do make sure to use FSMUti.isClean() which is a condition
for equality. I have considered other states (besides NEW and TRANSIENT)
but I am not bothered.
In what context would you need this kind
> of testing?
The context is a lookup function, so lookup ObjectX from a collection of
objects of type ObjectX whereby ObjectX is in transaction A and the
collection is from transaction B. The reason why the transactions are
separate has to do with longtivity of the transaction and memory
consumption. (As CDOTransactions hold references to objects) We read
millions of objects from files, we like to close the transaction after
one file is processed and keep one 'master' transaction with objects
which are more static during the whole process.
>>
>> Cheers Christophe
>>
>>
>>> cW
>>>
>>>
>>> On 2013-05-30 07:36:04 +0000, Christophe Bouhier said:
>>>
>>>> Hi,
>>>>
>>>> I just experienced something interesting today.
>>>>
>>>> Suppose
>>>>
>>>> CDOObject object .....
>>>>
>>>> CDOObject objectFromT1 = transaction1.getObject(object.cdoID);
>>>> CDOObject objectFromT2 = transaction2.getObject(object.cdoID);
>>>>
>>>> objectFromT1.equals(objetFromT2) => false
>>>>
>>>> hehe go figure...
>>>>
>>>> rgds Christophe
>>>
>>>
>>
>
|
|
| |
| Re: [CDO] CDOObject equality. [message #1061310 is a reply to message #1061231] |
Fri, 31 May 2013 03:17 |
| Eclipse User |
|
|
|
On 30-05-13 17:53, Eike Stepper wrote:
> Am 30.05.2013 16:35, schrieb Christophe Bouhier:
>> [...]
>>
>> In what context would you need this kind
>>> of testing?
>>
>> The context is a lookup function, so lookup ObjectX from a collection
>> of objects of type ObjectX whereby ObjectX is in transaction A and the
>> collection is from transaction B.
> As of Kepler M6 you can use objectX.cdoID() == objectY.cdoID() for a
> fast and "logical" equality check in an entire JVM.
Hey that's cool! thanks.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>> The reason why the transactions are separate has to do with longtivity
>> of the transaction and memory consumption. (As CDOTransactions hold
>> references to objects) We read millions of objects from files, we like
>> to close the transaction after one file is processed and keep one
>> 'master' transaction with objects which are more static during the
>> whole process.
>
|
|
|
Goto Forum:
Current Time: Thu Jul 10 23:23:49 EDT 2025
Powered by FUDForum. Page generated in 0.06927 seconds |
Home