Just postulating a theory here, but because we first set the ec fetch timestamp to current time, the refreshObjects will fetch fresh from the database due to out-of-date snapshots, and all other ec's get the benefit of the changed snapshots since snapshots are shared by all that are using the same OSC?
Anyway, I was pretty sure that thise worked for me before ..... I might write a test case some day when I get time, or maybe update the FreshnessExplorer.woa -Kieran On Feb 11, 2010, at 10:06 AM, Mike Schrag wrote: > as soon as i sent that i knew someone was going to call me on my lack of > clarity ... change that to "not necessarily fetched <in that ec>" if there > are affected snapshots fetched in other EC's in your app, you're only going > to refresh SOME of them. plus JFV is right that refreshObjects is not going > to refresh relationships, just the EO's. > > i'm kind of curious how hibernate addresses this when you use their caching > layers ... > > ms > > On Feb 11, 2010, at 10:01 AM, Anjo Krank wrote: > >> 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/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/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
