Re: refresh EC after call to ERXEOAccessUtilities.updateRowsDescribedByQualifier()?
Re: refresh EC after call to ERXEOAccessUtilities.updateRowsDescribedByQualifier()?
- Subject: Re: refresh EC after call to ERXEOAccessUtilities.updateRowsDescribedByQualifier()?
- From: Jean-Francois Veillette <email@hidden>
- Date: Thu, 11 Feb 2010 08:45:42 -0500
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden