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; 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.
John
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
