Re: TimeStamp LAG in editing context

A couple of points:

1. The lag is specified in milli-seconds.

2. The lag only affect what happens when an object is first brought into an 
editing context.  Regardless of what you do to the lag after this, the object 
will not be refreshed.

3. Using a low lag time *and* using a refreshing fetch spec caused a lot of 
problems with decrementSnapshotCountForGlobalID and 
incrementSnapshotCountForGlobalID.  Someone else said it was OK for them, so 
this might only affect inheritance.


Chuck


Jonathan Rochkind wrote:

> [Un-cross-posted from multiple groups; following up just to eof list].
> 
> At 10:31 AM 3/6/2003 -0300, Ing.Gaston Blanco wrote:
> 
>> I´m setting the lag in the editing context to 1 , then i create an EC, 
>> fetch an object. Then, from a sql terminal i change it, and when i 
>> refetch the changes are not reflected in my object. I believed that if 
>> the lag was to small the snapshot would be refreshed, and my object 
>> updated, but this didn´t happened.
> 
> 
> Well, here's a stab at explaining what's going on. The 'lag' you've set 
> refers to seconds (or ms, I forget, but time) _before the creation_ of 
> the EOEditingContext. If you've set it to 1 second, that means that EC 
> will make sure not to use snapshots OLDER than 1 second BEFORE the EC 
> was CREATED.  So changes that occured AFTER the EC was created----these 
> don't disturb the EC's commitment to not using snapshots older than 1 
> second before it was created.
> 
> Now you could constantly reset the EOEditingContext's fetchTimestamp(). 
> Note that the static method is called default timestamp LAG and means 
> that each EC, upon creation, will have it's timestamp set to that much 
> time earlier. But the instance method that applies to a particular 
> EOEditingContext is called setFetchTimestamp(), and takes an NSTimestamp 
> point-in-time---it's not a lag, it's an actual point-in-time, and the EC 
> will refuse to accept snapshots prior to this point in time.  So you 
> could be constantly resetting this fetchTimestamp to be just a few 
> seconds before NOW.  I'm not sure what effect this will have---it could 
> be deleterious on efficiency, as in-memory EOs are constantly refetched 
> because they're snapshots are no good. Alternately, it might not even do 
> what you want: I suspect it only effects _fetches_, it won't effect EOs 
> in memory, possibly unless you refetch those EOs. But you say you are 
> doing a refetch, so it might have the consequences you want.  In fact, 
> this might be a very good idea, but I'm not really sure, it makes me a 
> little bit nervous.
> 
> Alternately, you always have available to you: setting 
> refreshesRefetchedObjects to true on a particular EOFetchSpecification. 
> This means, regardless of the timestamp on the EC, when you do this 
> fetch, take the fresh values from the db and use them to create a new 
> snapshot.  It applies to just that one fetch spec, and the timestamp set 
> on the EC doesn't matter at all.
> 
> Hope this helps,
> --Jonathan
> 
> 
>> Any clue?????
>>
>> thanks
>>
>>
>> Ing. Gaston Blanco
>> __________________________________________________
>>
>> Todavía no tenés tu Ciudad Internet Mail? Obtenelo ahora! - 
>> http://webmail.ciudad.com.ar
>>
>> Descargá Gratis el nuevo Internet Explorer 6.0, el mejor software para 
>> actualizar tu PC.
>> http://www.ciudad.com.ar/ar/servicios/ie/
>>
>> _______________________________________________
>> EOF mailing list
>> [email protected]
>> http://www.omnigroup.com/mailman/listinfo/eof
> 
> 
> _______________________________________________
> EOF mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/eof


-- 

Chuck Hill                                 [email protected]
Global Village Consulting Inc.             http://www.global-village.net