true On Feb 11, 2010, at 9:14 AM, Jean-Francois Veillette wrote:
> > Le 10-02-11 à 09:05, Mike Schrag a écrit : > >> invalidateAllObjects can break other EC's that are currently editing objects >> because you throw away the backing snapshots from underneath them ... > > I forgot about that, thanks ! > Still, if users can't edit an eo instance in concurence, then it might be an > option, no? > > - jfv > >> 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
