On May 26, 2011, at 9:10 AM, John Huss wrote: > I'm far from an expert on this, but I've been digging in this code lately. > Look at EOEdtingContext._processObjectStoreChanges. > > The idea is that since the object was saved, the copies of it in memory in > other ECs are out of date and need to be re-read;
Changed objects are merged, unchanged objects are changed back into faults (I
think...) so that they get fresh data from the updated row in the database
context. It should not go back to the database. It might, though, if you have
a really recent fetch timestamp on the EC.
> I believe it is kind of leftover from the time when EOF was primarily a
> desktop framework. In that scenario you (might) want changes to an object to
> be reflected in all parts of the UI even if the object is in a different EC.
The changes should get reflected, but via notifications and updates from the
cached snapshot, not from another trip to the database (at least not by
default).
Chuck
> 2011/5/26 Paul Dunkler <paul.dunk...@xyrality.com>
> nice - thank you for the hint. I tried it and i was successfull. But in
> addition to this fix, it would be nice to know why the default behaviour of
> the editingContext is to refault all objects on saveChanges()... maybe anyone
> can explain?
>
>
> Am 26.05.2011 um 16:40 schrieb John Huss:
>
> > I would presume that this is happening in response to the
> > EOObjectsChangedInStoreNotification. You can implement an EOEditingContext
> > delegate and override editingContextShouldInvalidateObject to see where it
> > is happening and prevent it if you want.
> >
> > John
> >
> > On Thu, May 26, 2011 at 9:16 AM, Paul Dunkler <paul.dunk...@xyrality.com>
> > wrote:
> > Hey guys,
> >
> > we are currently developing a large webobjects (plus wonder of course)
> > driven backend application. Every time a request comes in, we fetch a big
> > set of data for the customer related to this request.
> > In the following actions we add/edit/delete some of the data originally
> > fetched from the database. At the end of each request, we do saveChanges()
> > on the editing context which holds our Customer Object with all it's
> > relationships.
> > After that all, we put a list of all the current data in the request's
> > response for delivering fresh informations to the client.
> >
> > The problem we get here is the following:
> > At the point of the request, where the fresh data is packed for presenting
> > it in the response, every access onto some of the attributes or
> > relationships from our Customer object lead us to a roundtrip in the
> > database. That is very expensive and it means, that our application is
> > performing the same Queries at the start of the request and at the end of
> > the request again...
> >
> > If my text was too complicated or incomprehensible, here is a short-termed
> > explanation of what i wanted to describe:
> > 1. Incoming request
> > 2. Batch fetching of the complete Customer-Object with all it's
> > relationships we want to access in the following code
> > 3. saveChanges() (somewhere in the process)
> > 4. Generating the response
> > -> Every call to a getter method (attributes) of the eo cause a roundtrip
> > to the database.
> >
> > We currently don't really know why this is happening. If we fetch an
> > object, change it's data, than save it - and then call a method on the same
> > object, why it has to do a new roundtrip to the database?
> >
> >
> > I just tried it out in a short DirectAction to check the behaviour:
> > > // WITH EDITING AN OBJECT
> > > Thing aThing = Thing.fetchThing(this.editingContext,
> > > Thing.NAME.eq("foo")); // <-- db-roundtrip
> > > System.out.println("first try: " +
> > > aThing.fooRelationshipArray());
> > > aThing.setBar(11);
> > > this.editingContext.saveChanges();
> > > System.out.println("second try: " +
> > > aThing.fooRelationshipArray()); // <-- db-roundtrip
> > > this.responseDictionary.setObjectForKey(aThing.bar(),
> > > "points");
> > >
> > > // WITHOUT EDITING AN OBJECT - WILL NOT DO A NEW ROUNDTRIP
> > > TO THE DATABASE
> > > Thing aSecondThing =
> > > Thing.fetchThing(this.editingContext(), Thing.PRIMARY_KEY_IDENTIFIER,
> > > 47); // <-- db-roundtrip
> > > System.out.println(aSecondThing.fooRelationshipArray());
> > > System.out.println("third try: " + aSecondThing); // <--
> > > no db-roundtrip
> > > System.out.println("fourth try: " + aSecondThing); // <--
> > > no db-roundtrip
> >
> >
> >
> > It would be very nice if you got any ideas to avoid this behaviour. Or some
> > nice thinkings about doing it right :)
> > I think this is a problem which can be solved - we browsed Webobjects Books
> > / Tutorials / Mailing List History, but had no luck at all....
> >
> >
> > --
> > Mit freundlichen Grüßen / Kind regards
> >
> > Paul Dunkler
> > _______________________________________________
> > 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/johnthuss%40gmail.com
> >
> > This email sent to johnth...@gmail.com
> >
>
> Mit freundlichen Grüßen
>
> Paul Dunkler
>
>
>
>
>
> -----------------------------------------------------
> XYRALITY GmbH • Lerchenstraße 28a • 22767 Hamburg
> Paul Dunkler • Softwareentwickler
> Mail: paul.dunk...@xyrality.com
> Tel: +49 (0) 40 23 51 78 97
> Mobil: +49 (0) 151 11624143
> Fax: +49 (0) 40 23 51 78 98
> Web: http://www.xyrality.com/
> Registergericht: Hamburg HRB 115332
> Geschäftsführer: Sven Ossenbrüggen & Alexander Spohr
> -----------------------------------------------------
>
>
>
> _______________________________________________
> 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/chill%40global-village.net
>
> This email sent to ch...@global-village.net
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC this July for unparalleled WO learning opportunities and real
peer to peer problem solving! Network, socialize, and enjoy a great
cosmopolitan city. See you there! http://www.wocommunity.org/wowodc11/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
