Am 26.05.2011 um 20:28 schrieb Chuck Hill: > > 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?
Hi Chuck, what dou you exactly want to have from me? I´m not really sure what you mean with stack traces in this case - no error is going to be produced - so there is not any stacktrace output produced. Or is there some magic parameter / log setting which let me see stack traces for direct action calls? > > > 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/ > Mit freundlichen Grüßen Paul Dunkler
<<inline: 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/archive%40mail-archive.com This email sent to [email protected]
