Really, IIRC, the code: ec.setFetchTimestamp( System.currentTimeMillis() ); ec.refreshAllObjects();
Try it. If it works, great. If not, let us know ;-) Kieran 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/kieran_lists%40mac.com > > This email sent to kieran_li...@mac.com _______________________________________________ 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
