On May 26, 2011, at 9:03 AM, Paul Dunkler wrote: > 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?
That is not the default behavior. I don't see this happening in my apps. Can you post the stack traces? Chuck > 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 <[email protected]> >> 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 ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/johnthuss%40gmail.com >> >> This email sent to [email protected] >> > > Mit freundlichen Grüßen > > Paul Dunkler > > > <xyrality_logo_medium.png> > > ----------------------------------------------------- > XYRALITY GmbH • Lerchenstraße 28a • 22767 Hamburg > Paul Dunkler • Softwareentwickler > Mail: [email protected] > 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 ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > > This email sent to [email protected] -- 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 ([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]
