Home » Modeling » EMF » [CDO] CDOObject equality.
|
| Re: [CDO] CDOObject equality. [message #1061184 is a reply to message #1061130] |
Thu, 30 May 2013 12:50   |
|
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?
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 #1061196 is a reply to message #1061184] |
Thu, 30 May 2013 13:30 |
 Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
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 13:54 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
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
>>
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] CDOObject equality. [message #1061213 is a reply to message #1061202] |
Thu, 30 May 2013 14:35 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
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
>>>
>>>
>>
>
|
|
| | |
Goto Forum:
Current Time: Tue Apr 16 10:52:56 GMT 2024
Powered by FUDForum. Page generated in 0.12315 seconds |
] 
Search
Help
Register
Login
Home
