[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GDL2: record -snapshot / toManyProperties / shallowCopy

From: David Ayers
Subject: Re: GDL2: record -snapshot / toManyProperties / shallowCopy
Date: Mon, 15 Aug 2005 22:50:08 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1

Manuel Guesdon schrieb:
> Hi,
> Searching for a bug, I've found that calling -snapshot on a record which have 
> toMany property fire toMany property value fault (if the value is still a 
> fault) when the shallowCopy is done (in EOClassDescription -snapshot) on line:
> value = AUTORELEASE([value shallowCopy]);
> This (can) produce uneeded ((too)many) fetches so I'm thinking about a way to 
> avoid this. 
> Do we really need this ?
>     I see 2 cases: 
>             1) If a change is made on the array, during save processing we'll 
> have to compare old and new values in the array.
>             2) If no change is made, we could ahave same fault in snapshot 
> and in object (it will be probably the most often case).
>    For 1), If we put a "Fault copy" in the snapshot, it will be de-faulted 
> during save processing (so we'll have 2 fetches: one for defaulting value 
> dring change and one during comparaison). I don't see problem doing the 
> snapshot de-fault only during comparaison, do you ?
>               We could also storing in snopshot a kind of fault which will 
> know when the orginal fault will be de-faulted (by the way of an observer ?). 
> When the original fault is de-faulted, it will default iteself, and take 
> original faut result 
> Any  think about this ?

I think 1) has the potential problem of "breaking" the lazy locking
principle: i.e.:

1) we fetch the master object and have a toMany fault.
2) we take the snapshot
3) we fire the object fault and modify the array
4) someone else fetches the same object, modifies the array and commits.
5) we save, firing the snapshot fault with the new values and therefore
we override the other users changes instead of getting the exception.

This is all theoretical speculation though, I hope to be able to write a
test case soon, but I think we may have to put some magic into
NSArray/EOCheapArray -shallowCopy and/or EOArrayFault.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]