[Top][All Lists]

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

Re[2]: GDL2: record -snapshot / toManyProperties / shallowCopy

From: Manuel Guesdon
Subject: Re[2]: GDL2: record -snapshot / toManyProperties / shallowCopy
Date: Tue, 16 Aug 2005 13:34:01 +0200 (CEST)

On Mon, 15 Aug 2005 22:50:08 +0200 David Ayers <address@hidden> wrote:

 >| 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 
 >| > 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.

I think you're right :-(

 >| 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.

Do you have ideas on this kind of magic ?

Here are some...
We could make database computing a digest of the toMany primaryKeys and raise 
the exception if it mismatch.
OK, if it match we are not sure that nothing changed. May be an array of all 
primary keys ? It will be faster and less memory consuming than creating 'real' 
records (even if we have some cases where we'll have to fetch reacords after) 
even more if PK is a single integer field. Or may be a an array wich can 
contain PK or records (PK if record is not alreay loaded or record if we have 

We could also store select results as a raw object to defer records creation 
(if we really need them later).


 >| Cheers,
 >| David


Manuel Guesdon

Manuel Guesdon - OXYMIUM <address@hidden>
14 rue Jean-Baptiste Clement  -  93200 Saint-Denis  -  France
Tel: +33 1 4940 0999  -  Fax: +33 1 4940 0998

reply via email to

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