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]
