But those not already fetched aren't a problem anyway? Cheers, Anjo
Am 11.02.2010 um 15:29 schrieb Mike Schrag: > that would only refresh the objects that were fetched into that EC, though, > right? i'm assuming he's doing a bulk operation on objects that were not > necessarily fetched. > > ms > > On Feb 11, 2010, at 9:17 AM, Kieran Kelleher wrote: > >> 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/mschrag%40mdimension.com >> >> This email sent to msch...@mdimension.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/anjo%40krank.net > > This email sent to a...@krank.net _______________________________________________ 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
