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
