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 ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
