Thanks for all your inputs. I will be doing couple of experiments Mike and
Kieran suggested and will post back soon with my observations/ any issues!
________________________________
From: Jean-Francois Veillette <jean_francois_veille...@yahoo.ca>
To: Kieran Kelleher <kieran_li...@mac.com>
Cc: Shravan Kumar.M <mshravan_...@yahoo.com>; WO Dev Group
<webobjects-dev@lists.apple.com>
Sent: Thu, February 11, 2010 8:09:04 PM
Subject: Re: refresh EC after call to
ERXEOAccessUtilities.updateRowsDescribedByQualifier()?
Le 10-02-11 à 09:17, Kieran Kelleher a écrit :
> Really, IIRC, the code:
>
> ec.setFetchTimestamp( System.currentTimeMillis() );
> ec.refreshAllObjects();
That would take care of attributes,
but would it take care of relationships ?
what about deleted eo's ?
> Try it. If it works, great. If not, let us know ;-)
Yes please, let us know ;-)
- jfv
> On Feb 11, 2010, at 9:05 AM, Mike Schrag wrote:
>
>> invalidateAllObjects can break other EC's that are currently editing objects
>> because you throw away the backing snapshots from underneath them ...
>>
>> ms
>>
>> On Feb 11, 2010, at 8:45 AM, Jean-Francois Veillette wrote:
>>
>>> I'm surprised no one mentionned ec.invalidateAllObjects() coupled with
>>> refetching arrays you might have in memory (displaygroup and such for
>>> example), as far as I understand, it's the only solution that will take
>>> care of relationship and get rid of deleted objects (faults will still be
>>> in memory but at least refetching relationship and arrays will avoid
>>> pointing to them).
>>>
>>> - jfv
>>>
>>> Le 10-02-08 à 14:20, Mike Schrag a écrit :
>>>
>>>> yeah, this is why i'm suspicious that we'll see a generalized Wonder
>>>> implementation of this .... definitely some tricks we could do, like what
>>>> you're saying -- just changing attributes that don't participate in
>>>> relationships, inverse relationships, or restricting qualifiers could be a
>>>> relatively easy update. changing anything that participates in a
>>>> relationship would be sort of a pain -- you have to do that pre-fetch
>>>> thing first and then you'd have to fake notifications afterwards. for
>>>> delete, it's even nastier.
>>>>
>>>> i think you take advantage of the knowledge you have of your special case
>>>> and custom write this. it's topics like these that make me sometimes think
>>>> the everything-is-cached approach is overkill. i'd love to see a variant
>>>> of EOF that lets you write like a stateless framework in cases where you
>>>> don't want all the snapshotting stuff.
>>>>
>>>> ms
>>>>
>>>> On Feb 8, 2010, at 2:13 PM, Anjo Krank wrote:
>>>>
>>>>> Mostly, it depends on what you are doing. Changing, say, status=done is
>>>>> different from owner=<people pk:1>, because the one only changes internal
>>>>> state, the other touches relationships.
>>>>>
>>>>> Then again, all your *other* ECs in all *other* instances won't get
>>>>> notified anyway (unless you use the ERCNF). So your code needs to be able
>>>>> to handle that problem anyway.
>>>>>
>>>>> Cheers, Anjo
>>>>>
>>>>>
>>>>>
>>>>> Am 08.02.2010 um 20:02 schrieb Mike Schrag:
>>>>>
>>>>>>> Mike's precautionary measure is ticking at the top of my mind... so may
>>>>>>> be for the time being I will just call ec.refreshAllObjects() just to
>>>>>>> be integral, consistent, simple and more importantly let not annoy EOF
>>>>>>> by mistake!!!
>>>>>> my precautionary tale is about using the methods you're using at all
>>>>>> (i.e. the updateRowsDescribedByQualifier) ... you're sneaking behind EOF
>>>>>> and basically doing direct DB operations. you're then trying to come
>>>>>> back and expect an easy way for EOF's caches to be in-sync with your
>>>>>> changes. the general case here is that you can't do it without tossing
>>>>>> all your snapshots, because you have no idea if the snapshots in your
>>>>>> cache are actually in-sync with the current state of the database when
>>>>>> you executed your update. there's a reason EOF does what it does when
>>>>>> you perform all of these operations, and it's because it actually needs
>>>>>> to.
>>>>>>
>>>>>> probably the closest-to-right way to do this is to prefetch the rows
>>>>>> that would be updated or deleted, perform the operations, then use the
>>>>>> GIDs to ... i guess manually do everything that EOF would have done.
>>>>>> you're going to lose all the inverse relationship updating, and you're
>>>>>> going to lose delete rules, etc. also, by fetching into the EC
>>>>>> beforehand, you're basically taking the performance hit that you were
>>>>>> probably trying to avoid in the first place by using those API's.
>>>>>>
>>>>>> so i doubt there's a simple generalized API that will go into Wonder for
>>>>>> this -- i'm not people would be happy with the performance profile of it.
>>>>>>
>>>>>> ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
