That presumes that all the EOs you touched with your bulk operation where
fetched into the EC you're refreshing. Picture:
Person 1
enabled = true
Person 2
enabled = true
Person 3
enabled = true
EC1
has Person 1 and Person 2 fetched
EC2
has Person 1 and Person 3 fetched
bulk update and set enabled = false for all Person objects
EC1.refreshAllObjects
in EC2, you've got Person 3 which is out-of-date and doesn't know it, though ...
Now, in the grand scheme of things, this is no different than any other
out-of-sync EOF issue. It just happens that for almost all the apps I work on,
nothing touches the databases that we use with EOF except EOF, so I never
really deal with this. If you have an app that is being modified by other
things in the background, you're already basically dealing with this problem.
However, the general answer to "how do i make sure EOF is fully up-to-date with
the database" is just a hard one ... The only REAL way is to throw away all
your caches, except that you can cause issues with current edits if you do that
without being careful.
ms
On Feb 11, 2010, at 12:22 PM, Kieran Kelleher wrote:
> 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 ([email protected])
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com
>>>>>>
>>>>>> This email sent to [email protected]
>>>>>
>>>>> _______________________________________________
>>>>> 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/mschrag%40mdimension.com
>>>>>
>>>>> This email sent to [email protected]
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/anjo%40krank.net
>>>>
>>>> This email sent to [email protected]
>>>
>>> _______________________________________________
>>> 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/mschrag%40mdimension.com
>>>
>>> This email sent to [email protected]
>>
>>
>> _______________________________________________
>> 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/kieran_lists%40mac.com
>>
>> This email sent to [email protected]
>
_______________________________________________
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]
