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 09:39:04 -0500
Le 10-02-11 à 09:17, Kieran Kelleher a écrit :
Really, IIRC, the code:
ec.setFetchTimestamp( System.currentTimeMillis() );
ec.refreshAllObjects();
That would take care of attributes,
but would it take care of relationships ?
what about deleted eo's ?
Try it. If it works, great. If not, let us know ;-)
Yes please, let us know ;-)
- jfv
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden