Re: AW: Weird Behaviour...
Hi Frank, A couple of notes: On 2011-12-12, at 12:49 AM, Ruenagel, Frank wrote: > Hi Ramsey, hi Chuck, > > well, I prefer a batch-like scenario for a test case. I have tried to distill > some code from Chucks instructive clarifications. > > The supposed problem: > An eo lives in a long running thread (1). It's state is changed in (1) but > not saved (first change). Other ECs meanwhile are busy saving and changing > the eo in different ECs and threads (2...n) to the database. > Then the thread (1) returns to action; another field of the same eo in the > same ec is changed in thread (1) (second change) and should be finally > saved. But this does not happen. There is no sql-update statement sent to the > database. > > I could reproduce this under the following 2 conditions: > > + editingContextShouldMergeChangesForObject returns false. I don't know why that is needed. > + the EC in thread A is temporarily unlocked while it is pausing and the > other ecs are acting . Unlocking and re-locking allows the EC to see changes from other editing contexts. > Indeed there is always missing a objectWillChange after the second change in > thread A. This is independent from the two conditions, but it only seem to > have measurable consequences in the above described situation. I don't know if you test case exactly matches what is happening in WO. This is all event driven (the notification comes from EOEventCenter) and should be triggered at the end of an "event" (e.g. the end of the RR-Loop by calling NSDelayedCallbackCenter.defaultCenter().eventEnded(). During one event in one thread, repeated objectWillChange notifications should NOT be sent from the same EO (waste of processing time). > But there may be other cases! This scares me. Calling > EOObserverCenter.notifyObserversObjectWillChange(null) right before the > second change resolves the situation, objectWillChange is sent. > > Details: > The code based on a simple long running thread (1) called in Application's > Constructor; the thread starts another short running thread (2). (2) then > lauchnes other saving threads 3-8 until (1) returns to action . The EO is > simple; > a java-class-file for it is not needed, simply create it in modeler. The > demo class "customer" has two Integer attributes , "age" and > "secondAttribute". Initiallly set them both to -1 or 0 per SQL. > > Tested both on WO 5.2.4 and WO 5.4.3 . > > Regards > Frank Ruenagel > > > > -Ursprüngliche Nachricht- > Von: Ramsey Gurley [mailto:rgur...@smarthealth.com] > Gesendet: Donnerstag, 8. Dezember 2011 17:50 > An: Ruenagel, Frank > Cc: Calven Eggert; Webobjects-dev@lists.apple.com > Betreff: Re: AW: Weird Behaviour... > > Distilling this down to a test case to demonstrate it would be nice. I don't > have time to do it myself, but this may even be demonstrable just using a > EditEntity direct action in ERD2W with no __cid. I think that will create an > edit page for the eo and would leave you on the page after save so editing > could continue in the same EC in a new worker thread. You would need to be > able to make edits without saving too, but that wouldn't be too hard to do > with an ajax type look like Modern. > > After reading Gary Teter's description of the problem and looking at the code > in EOObserverCenter, I can see how this could happen. EOObserverCenter is > depending on the EC to call notify(null) to clear the _ThreadInfo, but that > only affects the current thread. Assuming calling notify(null) has no > adverse effects, we should probably add that line to > ERXApplication._endRequest in my opinion. > > I've already committed said change in my local master. I'm going to play > around with it this weekend. If I don't see any strangeness, I plan to > commit it upstream barring any wailing and gnashing of teeth on the list :-) > > Ramsey > > On Dec 8, 2011, at 9:02 AM, Ruenagel, Frank wrote: > >> Hi Calven, >> >> your app is quite straight on and single threaded, which is the default in >> WO 5.3. I do not believe there is a problem with EOF. >> I guess the data entered/changed by the users change the condition, whether >> the save-button appears in the WOComponent (like ec.hasChanges()). >> The button will then disappear/appear in certain phases of the >> RR-Loop, which causes the trouble. This also explains, why you see the data >> in the form after this half-submit. This is an ugly trap in WO. IIRC, Chuck >> noted it anywhere in his book. >> >> This is just a guess. Additionally you seem to have foun
Re: Weird Behaviour...
Hi there, some time ago Ray added a number of JUnit tests to Wonder. Can I suggest you append to that work... it would benefit everyone if things were solved in a common / reusable place :) On 12/12/2011, at 7:49 PM, Ruenagel, Frank wrote: > Hi Ramsey, hi Chuck, > > well, I prefer a batch-like scenario for a test case. I have tried to distill > some code from Chucks instructive clarifications. > <...> Cheers Lachlan Deck lachlan.d...@gmail.com ___ 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
Re: AW: Weird Behaviour...
Hi Ramsey, hi Chuck, well, I prefer a batch-like scenario for a test case. I have tried to distill some code from Chucks instructive clarifications. The supposed problem: An eo lives in a long running thread (1). It's state is changed in (1) but not saved (first change). Other ECs meanwhile are busy saving and changing the eo in different ECs and threads (2...n) to the database. Then the thread (1) returns to action; another field of the same eo in the same ec is changed in thread (1) (second change) and should be finally saved. But this does not happen. There is no sql-update statement sent to the database. I could reproduce this under the following 2 conditions: + editingContextShouldMergeChangesForObject returns false. + the EC in thread A is temporarily unlocked while it is pausing and the other ecs are acting . Indeed there is always missing a objectWillChange after the second change in thread A. This is independent from the two conditions, but it only seem to have measurable consequences in the above described situation. But there may be other cases! This scares me. Calling EOObserverCenter.notifyObserversObjectWillChange(null) right before the second change resolves the situation, objectWillChange is sent. Details: The code based on a simple long running thread (1) called in Application's Constructor; the thread starts another short running thread (2). (2) then lauchnes other saving threads 3-8 until (1) returns to action . The EO is simple; a java-class-file for it is not needed, simply create it in modeler. The demo class "customer" has two Integer attributes , "age" and "secondAttribute". Initiallly set them both to -1 or 0 per SQL. Tested both on WO 5.2.4 and WO 5.4.3 . Regards Frank Ruenagel -Ursprüngliche Nachricht- Von: Ramsey Gurley [mailto:rgur...@smarthealth.com] Gesendet: Donnerstag, 8. Dezember 2011 17:50 An: Ruenagel, Frank Cc: Calven Eggert; Webobjects-dev@lists.apple.com Betreff: Re: AW: Weird Behaviour... Distilling this down to a test case to demonstrate it would be nice. I don't have time to do it myself, but this may even be demonstrable just using a EditEntity direct action in ERD2W with no __cid. I think that will create an edit page for the eo and would leave you on the page after save so editing could continue in the same EC in a new worker thread. You would need to be able to make edits without saving too, but that wouldn't be too hard to do with an ajax type look like Modern. After reading Gary Teter's description of the problem and looking at the code in EOObserverCenter, I can see how this could happen. EOObserverCenter is depending on the EC to call notify(null) to clear the _ThreadInfo, but that only affects the current thread. Assuming calling notify(null) has no adverse effects, we should probably add that line to ERXApplication._endRequest in my opinion. I've already committed said change in my local master. I'm going to play around with it this weekend. If I don't see any strangeness, I plan to commit it upstream barring any wailing and gnashing of teeth on the list :-) Ramsey On Dec 8, 2011, at 9:02 AM, Ruenagel, Frank wrote: > Hi Calven, > > your app is quite straight on and single threaded, which is the default in WO > 5.3. I do not believe there is a problem with EOF. > I guess the data entered/changed by the users change the condition, whether > the save-button appears in the WOComponent (like ec.hasChanges()). > The button will then disappear/appear in certain phases of the > RR-Loop, which causes the trouble. This also explains, why you see the data > in the form after this half-submit. This is an ugly trap in WO. IIRC, Chuck > noted it anywhere in his book. > > This is just a guess. Additionally you seem to have found a workaround > for this using EOObserverCenter.notifyObserversObjectWillChange(null) > in dispatchRequest. With this you force EOF to do things earlier than it > normally would do it. Congratulation! > > Cheers. > > Frank > > > -Ursprüngliche Nachricht- > Von: Calven Eggert [mailto:cegg...@uhnresearch.ca] > Gesendet: Donnerstag, 8. Dezember 2011 15:58 > An: Ruenagel, Frank > Betreff: Re: Weird Behaviour... > > > On 2011-12-08, at 5:05 AM, Ruenagel, Frank wrote: > >> Hi, >> >> I think a little bit more data would be helpful to write code, which >> simulates the situation. >> >> Calven, do you use one editingcontext (ec) over all sessions or in the whole >> app? > Although my app has child editingcontexts, in this part of the application > where the problem occurred there was only the session.defaulteditingcontext. > >> Are the saves done via a direct action? > no > >> Is it a session based app? Is
AW: Weird Behaviour...
Hi Calven, see Chuck's Book, page 191f. Regards Frank -Ursprüngliche Nachricht- Von: Calven Eggert [mailto:cegg...@uhnresearch.ca] Gesendet: Donnerstag, 8. Dezember 2011 17:30 An: Ruenagel, Frank Betreff: Re: Weird Behaviour... Can you please elaborate on this statement? > The button will then disappear/appear in certain phases of the RR-Loop, > which causes the trouble. ___ 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
Re: AW: Weird Behaviour...
On 2011-12-08, at 8:49 AM, Ramsey Gurley wrote: > Distilling this down to a test case to demonstrate it would be nice. I don't > have time to do it myself, but this may even be demonstrable just using a > EditEntity direct action in ERD2W with no __cid. I think that will create an > edit page for the eo and would leave you on the page after save so editing > could continue in the same EC in a new worker thread. You would need to be > able to make edits without saving too, but that wouldn't be too hard to do > with an ajax type look like Modern. > > After reading Gary Teter's description of the problem and looking at the code > in EOObserverCenter, I can see how this could happen. EOObserverCenter is > depending on the EC to call notify(null) to clear the _ThreadInfo, but that > only affects the current thread. Assuming calling notify(null) has no > adverse effects, we should probably add that line to > ERXApplication._endRequest in my opinion. It does not have any adverse effects. If severals EOs are edited during one RR loop (not an unusual situation), this value will change with the last object being edited. The only purpose of this is to prevent re-broadcast of identical notifications as a performance optimization. Chuck > > > I've already committed said change in my local master. I'm going to play > around with it this weekend. If I don't see any strangeness, I plan to > commit it upstream barring any wailing and gnashing of teeth on the list :-) > > Ramsey > > On Dec 8, 2011, at 9:02 AM, Ruenagel, Frank wrote: > >> Hi Calven, >> >> your app is quite straight on and single threaded, which is the default in >> WO 5.3. I do not believe there is a problem with EOF. >> I guess the data entered/changed by the users change the condition, whether >> the save-button appears in the WOComponent (like ec.hasChanges()). >> The button will then disappear/appear in certain phases of the RR-Loop, >> which causes the trouble. This also explains, why you see the >> data in the form after this half-submit. This is an ugly trap in WO. IIRC, >> Chuck noted it anywhere in his book. >> >> This is just a guess. Additionally you seem to have found a workaround for >> this using EOObserverCenter.notifyObserversObjectWillChange(null) >> in dispatchRequest. With this you force EOF to do things earlier than it >> normally would do it. Congratulation! >> >> Cheers. >> >> Frank >> >> >> -Ursprüngliche Nachricht- >> Von: Calven Eggert [mailto:cegg...@uhnresearch.ca] >> Gesendet: Donnerstag, 8. Dezember 2011 15:58 >> An: Ruenagel, Frank >> Betreff: Re: Weird Behaviour... >> >> >> On 2011-12-08, at 5:05 AM, Ruenagel, Frank wrote: >> >>> Hi, >>> >>> I think a little bit more data would be helpful to write code, which >>> simulates the situation. >>> >>> Calven, do you use one editingcontext (ec) over all sessions or in the >>> whole app? >> Although my app has child editingcontexts, in this part of the application >> where the problem occurred there was only the session.defaulteditingcontext. >> >>> Are the saves done via a direct action? >> no >> >>> Is it a session based app? Is the session ec used? >> yes and yes. >> >>> If there are multiple ecs: How are the Eos created? With a fetch? When in >>> the RR Loop? >> with a fetch. when? I don't know how to answer that question. A user >> enters data into a search field and a fetch is performed. >> >>> Are there multiple StoreCoodinators or one? >> 1. (FYI - there are multiple eomodels) >> >>> Is the save-button wrapped by a conditional? >> yes. >> >>> Are all data unconditionally in a form? >> Not sure what you mean. >> >>> Do you hit the Save-Button or did you hit the "Return"-key and the >>> save-button is not the default action of the form and there is another >>> button? >> save button. >> >>> After hitting the save button: has the snapshot of the eo the right values >>> or not? >> I don't know. I would assume yes because the values on the screen are >> correct. >> >>> >>> Is setAllowsConcurrentRequestHandling(true or false) ? >>> >> I don't use that call so I would say that whatever the default is that's >> what mine is. >> >>> Regards >>> Frank >>> >>> >>> -Ursprüngliche Nachricht
Re: AW: Weird Behaviour...
Hi Frank, On 2011-12-08, at 8:02 AM, Ruenagel, Frank wrote: > Hi Calven, > > your app is quite straight on and single threaded, which is the default in WO > 5.3. I do not believe there is a problem with EOF. > I guess the data entered/changed by the users change the condition, whether > the save-button appears in the WOComponent (like ec.hasChanges()). > The button will then disappear/appear in certain phases of the RR-Loop, > which causes the trouble. This also explains, why you see the > data in the form after this half-submit. This is an ugly trap in WO. IIRC, > Chuck noted it anywhere in his book. > > This is just a guess. Additionally you seem to have found a workaround for > this using EOObserverCenter.notifyObserversObjectWillChange(null) > in dispatchRequest. With this you force EOF to do things earlier than it > normally would do it. Congratulation! That is not a work around that is directly fixing an issue with WO/EOF. It does not force EOF to do things earlier (like ec.processRecentChanges() does), it just clears the way for the normal notifications to be broadcast. Chuck > -Ursprüngliche Nachricht- > Von: Calven Eggert [mailto:cegg...@uhnresearch.ca] > Gesendet: Donnerstag, 8. Dezember 2011 15:58 > An: Ruenagel, Frank > Betreff: Re: Weird Behaviour... > > > On 2011-12-08, at 5:05 AM, Ruenagel, Frank wrote: > >> Hi, >> >> I think a little bit more data would be helpful to write code, which >> simulates the situation. >> >> Calven, do you use one editingcontext (ec) over all sessions or in the whole >> app? > Although my app has child editingcontexts, in this part of the application > where the problem occurred there was only the session.defaulteditingcontext. > >> Are the saves done via a direct action? > no > >> Is it a session based app? Is the session ec used? > yes and yes. > >> If there are multiple ecs: How are the Eos created? With a fetch? When in >> the RR Loop? > with a fetch. when? I don't know how to answer that question. A user > enters data into a search field and a fetch is performed. > >> Are there multiple StoreCoodinators or one? > 1. (FYI - there are multiple eomodels) > >> Is the save-button wrapped by a conditional? > yes. > >> Are all data unconditionally in a form? > Not sure what you mean. > >> Do you hit the Save-Button or did you hit the "Return"-key and the >> save-button is not the default action of the form and there is another >> button? > save button. > >> After hitting the save button: has the snapshot of the eo the right values >> or not? > I don't know. I would assume yes because the values on the screen are > correct. > >> >> Is setAllowsConcurrentRequestHandling(true or false) ? >> > I don't use that call so I would say that whatever the default is that's what > mine is. > >> Regards >> Frank >> >> >> -Ursprüngliche Nachricht- >> Von: webobjects-dev-bounces+webobjects=symposion...@lists.apple.com >> [mailto:webobjects-dev-bounces+webobjects=symposion...@lists.apple.com >> ] Im Auftrag von Calven Eggert >> Bereitgestellt: Donnerstag, 8. Dezember 2011 05:05 Bereitgestellt in: >> WebObjects >> Unterhaltung: Weird Behaviour... >> Betreff: Re: Weird Behaviour... >> >> >> On 2011-12-07, at 4:11 PM, Chuck Hill wrote: >> >>> >>> On 2011-12-07, at 12:06 PM, Calven Eggert wrote: >>> >>>> It might be helpful to know that I've discovered that my application that >>>> was having this problem allows the user to click on a record in a list to >>>> go to an edit page. On the edit page there is a save button and when >>>> clicked the page remains displayed. My other WO apps do not have this >>>> behaviour, the save button returns the user to the list page and so far I >>>> have not found any issues with data not being saved in the database. >>> >>> Does the editing page make any automated changes before the user initiates >>> a save? I am thinking of something like setting a lastModified timestamp. >>> That would make the problem much more prevalent. >> >> Nope. >> >>> >>> Chuck >>> >>> >>>> This all seems to fit in with how the bug is described earlier from >>>> Phillippe and Chuck's additional comment. (In my testing I was >>>> editing a record hitting save and editing again immediately on the >>>> same page. After approximately 7
Re: AW: Weird Behaviour...
Distilling this down to a test case to demonstrate it would be nice. I don't have time to do it myself, but this may even be demonstrable just using a EditEntity direct action in ERD2W with no __cid. I think that will create an edit page for the eo and would leave you on the page after save so editing could continue in the same EC in a new worker thread. You would need to be able to make edits without saving too, but that wouldn't be too hard to do with an ajax type look like Modern. After reading Gary Teter's description of the problem and looking at the code in EOObserverCenter, I can see how this could happen. EOObserverCenter is depending on the EC to call notify(null) to clear the _ThreadInfo, but that only affects the current thread. Assuming calling notify(null) has no adverse effects, we should probably add that line to ERXApplication._endRequest in my opinion. I've already committed said change in my local master. I'm going to play around with it this weekend. If I don't see any strangeness, I plan to commit it upstream barring any wailing and gnashing of teeth on the list :-) Ramsey On Dec 8, 2011, at 9:02 AM, Ruenagel, Frank wrote: > Hi Calven, > > your app is quite straight on and single threaded, which is the default in WO > 5.3. I do not believe there is a problem with EOF. > I guess the data entered/changed by the users change the condition, whether > the save-button appears in the WOComponent (like ec.hasChanges()). > The button will then disappear/appear in certain phases of the RR-Loop, > which causes the trouble. This also explains, why you see the > data in the form after this half-submit. This is an ugly trap in WO. IIRC, > Chuck noted it anywhere in his book. > > This is just a guess. Additionally you seem to have found a workaround for > this using EOObserverCenter.notifyObserversObjectWillChange(null) > in dispatchRequest. With this you force EOF to do things earlier than it > normally would do it. Congratulation! > > Cheers. > > Frank > > > -Ursprüngliche Nachricht- > Von: Calven Eggert [mailto:cegg...@uhnresearch.ca] > Gesendet: Donnerstag, 8. Dezember 2011 15:58 > An: Ruenagel, Frank > Betreff: Re: Weird Behaviour... > > > On 2011-12-08, at 5:05 AM, Ruenagel, Frank wrote: > >> Hi, >> >> I think a little bit more data would be helpful to write code, which >> simulates the situation. >> >> Calven, do you use one editingcontext (ec) over all sessions or in the whole >> app? > Although my app has child editingcontexts, in this part of the application > where the problem occurred there was only the session.defaulteditingcontext. > >> Are the saves done via a direct action? > no > >> Is it a session based app? Is the session ec used? > yes and yes. > >> If there are multiple ecs: How are the Eos created? With a fetch? When in >> the RR Loop? > with a fetch. when? I don't know how to answer that question. A user > enters data into a search field and a fetch is performed. > >> Are there multiple StoreCoodinators or one? > 1. (FYI - there are multiple eomodels) > >> Is the save-button wrapped by a conditional? > yes. > >> Are all data unconditionally in a form? > Not sure what you mean. > >> Do you hit the Save-Button or did you hit the "Return"-key and the >> save-button is not the default action of the form and there is another >> button? > save button. > >> After hitting the save button: has the snapshot of the eo the right values >> or not? > I don't know. I would assume yes because the values on the screen are > correct. > >> >> Is setAllowsConcurrentRequestHandling(true or false) ? >> > I don't use that call so I would say that whatever the default is that's what > mine is. > >> Regards >> Frank >> >> >> -Ursprüngliche Nachricht- >> Von: webobjects-dev-bounces+webobjects=symposion...@lists.apple.com >> [mailto:webobjects-dev-bounces+webobjects=symposion...@lists.apple.com >> ] Im Auftrag von Calven Eggert >> Bereitgestellt: Donnerstag, 8. Dezember 2011 05:05 Bereitgestellt in: >> WebObjects >> Unterhaltung: Weird Behaviour... >> Betreff: Re: Weird Behaviour... >> >> >> On 2011-12-07, at 4:11 PM, Chuck Hill wrote: >> >>> >>> On 2011-12-07, at 12:06 PM, Calven Eggert wrote: >>> >>>> It might be helpful to know that I've discovered that my application that >>>> was having this problem allows the user to click on a record in a list to >>>> go to an edit
AW: Weird Behaviour...
Hi Calven, your app is quite straight on and single threaded, which is the default in WO 5.3. I do not believe there is a problem with EOF. I guess the data entered/changed by the users change the condition, whether the save-button appears in the WOComponent (like ec.hasChanges()). The button will then disappear/appear in certain phases of the RR-Loop, which causes the trouble. This also explains, why you see the data in the form after this half-submit. This is an ugly trap in WO. IIRC, Chuck noted it anywhere in his book. This is just a guess. Additionally you seem to have found a workaround for this using EOObserverCenter.notifyObserversObjectWillChange(null) in dispatchRequest. With this you force EOF to do things earlier than it normally would do it. Congratulation! Cheers. Frank -Ursprüngliche Nachricht- Von: Calven Eggert [mailto:cegg...@uhnresearch.ca] Gesendet: Donnerstag, 8. Dezember 2011 15:58 An: Ruenagel, Frank Betreff: Re: Weird Behaviour... On 2011-12-08, at 5:05 AM, Ruenagel, Frank wrote: > Hi, > > I think a little bit more data would be helpful to write code, which > simulates the situation. > > Calven, do you use one editingcontext (ec) over all sessions or in the whole > app? Although my app has child editingcontexts, in this part of the application where the problem occurred there was only the session.defaulteditingcontext. > Are the saves done via a direct action? no > Is it a session based app? Is the session ec used? yes and yes. > If there are multiple ecs: How are the Eos created? With a fetch? When in > the RR Loop? with a fetch. when? I don't know how to answer that question. A user enters data into a search field and a fetch is performed. > Are there multiple StoreCoodinators or one? 1. (FYI - there are multiple eomodels) > Is the save-button wrapped by a conditional? yes. > Are all data unconditionally in a form? Not sure what you mean. > Do you hit the Save-Button or did you hit the "Return"-key and the > save-button is not the default action of the form and there is another button? save button. > After hitting the save button: has the snapshot of the eo the right values or > not? I don't know. I would assume yes because the values on the screen are correct. > > Is setAllowsConcurrentRequestHandling(true or false) ? > I don't use that call so I would say that whatever the default is that's what mine is. > Regards > Frank > > > -Ursprüngliche Nachricht- > Von: webobjects-dev-bounces+webobjects=symposion...@lists.apple.com > [mailto:webobjects-dev-bounces+webobjects=symposion...@lists.apple.com > ] Im Auftrag von Calven Eggert > Bereitgestellt: Donnerstag, 8. Dezember 2011 05:05 Bereitgestellt in: > WebObjects > Unterhaltung: Weird Behaviour... > Betreff: Re: Weird Behaviour... > > > On 2011-12-07, at 4:11 PM, Chuck Hill wrote: > >> >> On 2011-12-07, at 12:06 PM, Calven Eggert wrote: >> >>> It might be helpful to know that I've discovered that my application that >>> was having this problem allows the user to click on a record in a list to >>> go to an edit page. On the edit page there is a save button and when >>> clicked the page remains displayed. My other WO apps do not have this >>> behaviour, the save button returns the user to the list page and so far I >>> have not found any issues with data not being saved in the database. >> >> Does the editing page make any automated changes before the user initiates a >> save? I am thinking of something like setting a lastModified timestamp. >> That would make the problem much more prevalent. > > Nope. > >> >> Chuck >> >> >>> This all seems to fit in with how the bug is described earlier from >>> Phillippe and Chuck's additional comment. (In my testing I was >>> editing a record hitting save and editing again immediately on the >>> same page. After approximately 7 saves in a row the problem arose. >>> In any case, this is now resolved with the suggested fix.) >>> >>> On 2011-12-07, at 11:01 AM, Ramsey Gurley wrote: >>> >>>> >>>> On Dec 6, 2011, at 3:43 PM, Chuck Hill wrote: >>>> >>>>> >>>>> On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: >>>>> >>>>>> On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: >>>>>> >>>>>>> I can feel how uncomfortable you are. >>>>>>> >>>>>>> What makes me confused is to never see this bug before. It's hard to >>>>>>> believe that nobody
AW: Weird Behaviour...
Hi, I think a little bit more data would be helpful to write code, which simulates the situation. Calven, do you use one editingcontext (ec) over all sessions or in the whole app? Are the saves done via a direct action? Is it a session based app? Is the session ec used? If there are multiple ecs: How are the Eos created? With a fetch? When in the RR Loop? Are there multiple StoreCoodinators or one? Is the save-button wrapped by a conditional? Are all data unconditionally in a form? Do you hit the Save-Button or did you hit the "Return"-key and the save-button is not the default action of the form and there is another button? After hitting the save button: has the snapshot of the eo the right values or not? Is setAllowsConcurrentRequestHandling(true or false) ? Regards Frank -Ursprüngliche Nachricht- Von: webobjects-dev-bounces+webobjects=symposion...@lists.apple.com [mailto:webobjects-dev-bounces+webobjects=symposion...@lists.apple.com] Im Auftrag von Calven Eggert Bereitgestellt: Donnerstag, 8. Dezember 2011 05:05 Bereitgestellt in: WebObjects Unterhaltung: Weird Behaviour... Betreff: Re: Weird Behaviour... On 2011-12-07, at 4:11 PM, Chuck Hill wrote: > > On 2011-12-07, at 12:06 PM, Calven Eggert wrote: > >> It might be helpful to know that I've discovered that my application that >> was having this problem allows the user to click on a record in a list to go >> to an edit page. On the edit page there is a save button and when clicked >> the page remains displayed. My other WO apps do not have this behaviour, >> the save button returns the user to the list page and so far I have not >> found any issues with data not being saved in the database. > > Does the editing page make any automated changes before the user initiates a > save? I am thinking of something like setting a lastModified timestamp. > That would make the problem much more prevalent. Nope. > > Chuck > > >> This all seems to fit in with how the bug is described earlier from >> Phillippe and Chuck's additional comment. (In my testing I was editing a >> record hitting save and editing again immediately on the same page. After >> approximately 7 saves in a row the problem arose. In any case, this is now >> resolved with the suggested fix.) >> >> On 2011-12-07, at 11:01 AM, Ramsey Gurley wrote: >> >>> >>> On Dec 6, 2011, at 3:43 PM, Chuck Hill wrote: >>> >>>> >>>> On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: >>>> >>>>> On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: >>>>> >>>>>> I can feel how uncomfortable you are. >>>>>> >>>>>> What makes me confused is to never see this bug before. It's hard to >>>>>> believe that nobody saw the errors if there are error. But on another >>>>>> side, I (and all the team) worked on many applications so following the >>>>>> explanation, I don't know why we don't see this issue much more often. >>>>> >>>>> I suspect the more prevalent use of concurrent requests these days has >>>>> exposed this bug. >>>> >>>> It is worth carefully reading over the reproduction steps: >>>> >>>>> * How it fails: A request is handled by WorkerThread0. By the end of >>>>> the request the eo has been modified but not saved, so the >>>>> EOObserverCenter remembers >>>>> * that WorkerThread0's most recent object is that eo. Fifteen more >>>>> requests are handled by WorkerThreads 1-15 in sequence. One of these >>>>> requests completes >>>>> * the modification of the eo and calls saveChanges on the ec. At >>>>> this point the ec tells the EOObserverCenter to forget about its most >>>>> recent object, but >>>>> * it's being set to null in WorkerThread14 or whatever, not >>>>> WorkerThread0. >>>>> * >>>>> * The next request will wrap around to to be handled by >>>>> WorkerThread0. This request modifies an attribute on the eo, but since >>>>> the EOObserverCenter still >>>>> * thinks WorkerThread0 has already noticed the eo, it ignores the >>>>> willChange and the ec doesn't grab a snapshot. >>>>> * >>>>> * Later in the processing of this request, a different object gets >>>>> changed, willChange gets called and the ec grabs a snapshot of the second >>>>> o
Re: Weird Behaviour...
On 2011-12-07, at 4:11 PM, Chuck Hill wrote: > > On 2011-12-07, at 12:06 PM, Calven Eggert wrote: > >> It might be helpful to know that I've discovered that my application that >> was having this problem allows the user to click on a record in a list to go >> to an edit page. On the edit page there is a save button and when clicked >> the page remains displayed. My other WO apps do not have this behaviour, >> the save button returns the user to the list page and so far I have not >> found any issues with data not being saved in the database. > > Does the editing page make any automated changes before the user initiates a > save? I am thinking of something like setting a lastModified timestamp. > That would make the problem much more prevalent. Nope. > > Chuck > > >> This all seems to fit in with how the bug is described earlier from >> Phillippe and Chuck's additional comment. (In my testing I was editing a >> record hitting save and editing again immediately on the same page. After >> approximately 7 saves in a row the problem arose. In any case, this is now >> resolved with the suggested fix.) >> >> On 2011-12-07, at 11:01 AM, Ramsey Gurley wrote: >> >>> >>> On Dec 6, 2011, at 3:43 PM, Chuck Hill wrote: >>> On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: > On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: > >> I can feel how uncomfortable you are. >> >> What makes me confused is to never see this bug before. It's hard to >> believe that nobody saw the errors if there are error. But on another >> side, I (and all the team) worked on many applications so following the >> explanation, I don't know why we don't see this issue much more often. > > I suspect the more prevalent use of concurrent requests these days has > exposed this bug. It is worth carefully reading over the reproduction steps: > * How it fails: A request is handled by WorkerThread0. By the end of > the request the eo has been modified but not saved, so the > EOObserverCenter remembers > * that WorkerThread0's most recent object is that eo. Fifteen more > requests are handled by WorkerThreads 1-15 in sequence. One of these > requests completes > * the modification of the eo and calls saveChanges on the ec. At > this point the ec tells the EOObserverCenter to forget about its most > recent object, but > * it's being set to null in WorkerThread14 or whatever, not > WorkerThread0. > * > * The next request will wrap around to to be handled by > WorkerThread0. This request modifies an attribute on the eo, but since > the EOObserverCenter still > * thinks WorkerThread0 has already noticed the eo, it ignores the > willChange and the ec doesn't grab a snapshot. > * > * Later in the processing of this request, a different object gets > changed, willChange gets called and the ec grabs a snapshot of the second > object. Then, > * a change gets made to the original eo, willChange gets called, and > since the EOObserverCenter was paying attention to the second object, it > goes ahead > * and notifies the ec about the first object. > * > * At this point the ec grabs a snapshot of the first object, but > it's too late -- the object has already been modified, the ec didn't know > about the > * previous change, so when saveChanges gets called the previous > changes don't get saved to the database. And now your object graph no > longer matches the > * database, and your app is borked. Note that it has to be the _same_ eo (same GID) and the same thread and it has to be in a modified but unsaved state. >>> >>> In EOObserverCenter I see: >>> >>> eo == threadInfo._lastWillChangeObject >>> >>> Same ec, multiple threads.. oy! >>> >>> It stands to reason that when the ec is saved, any eo in that ec should be >>> removed from the threadInfos. It sounds like the _ThreadInfo should set up >>> an observer on the ec's EditingContextDidSaveChangesNotification. Once >>> saved, any threadInfo with an eo in that ec should set >>> _lastWillChangeObject to null. >>> >>> I wonder what about nested ECs? Let's say the parent ec is saved, but the >>> nested ec has changes to an EO already. What then? >>> >>> My guess is that unless your users are doing highly concurrent editing of the same data that this will rarely affect you. That is why I found it fixing Calven's problem so readily a surprise. >> And a question regarding the workaround: is there any drawback to call >> the EOObserver in the dispatchRequest method like suggested? > > For multiple active worker threads, a good question... > > Lachlan Deck > lachlan.d...@gmail.com >>
Re: Weird Behaviour...
On 2011-12-07, at 2:22 PM, Ramsey Gurley wrote: > On Dec 7, 2011, at 2:30 PM, Chuck Hill wrote: > On 2011-12-07, at 8:01 AM, Ramsey Gurley wrote: >>> On Dec 6, 2011, at 3:43 PM, Chuck Hill wrote: On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: > On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: > >> I can feel how uncomfortable you are. >> >> What makes me confused is to never see this bug before. It's hard to >> believe that nobody saw the errors if there are error. But on another >> side, I (and all the team) worked on many applications so following the >> explanation, I don't know why we don't see this issue much more often. > > I suspect the more prevalent use of concurrent requests these days has > exposed this bug. It is worth carefully reading over the reproduction steps: > * How it fails: A request is handled by WorkerThread0. By the end of > the request the eo has been modified but not saved, so the > EOObserverCenter remembers > * that WorkerThread0's most recent object is that eo. Fifteen more > requests are handled by WorkerThreads 1-15 in sequence. One of these > requests completes > * the modification of the eo and calls saveChanges on the ec. At > this point the ec tells the EOObserverCenter to forget about its most > recent object, but > * it's being set to null in WorkerThread14 or whatever, not > WorkerThread0. > * > * The next request will wrap around to to be handled by > WorkerThread0. This request modifies an attribute on the eo, but since > the EOObserverCenter still > * thinks WorkerThread0 has already noticed the eo, it ignores the > willChange and the ec doesn't grab a snapshot. > * > * Later in the processing of this request, a different object gets > changed, willChange gets called and the ec grabs a snapshot of the second > object. Then, > * a change gets made to the original eo, willChange gets called, and > since the EOObserverCenter was paying attention to the second object, it > goes ahead > * and notifies the ec about the first object. > * > * At this point the ec grabs a snapshot of the first object, but > it's too late -- the object has already been modified, the ec didn't know > about the > * previous change, so when saveChanges gets called the previous > changes don't get saved to the database. And now your object graph no > longer matches the > * database, and your app is borked. Note that it has to be the _same_ eo (same GID) and the same thread and it has to be in a modified but unsaved state. >>> >>> In EOObserverCenter I see: >>> >>> eo == threadInfo._lastWillChangeObject >>> >>> Same ec, multiple threads.. oy! >> >> Not sure what is concerning you there. _lastWillChangeObject is just a >> performance optimization to avoid sending repeat, identical notifications. >> I don't think it is getting used by two threads at once, at least not in the >> sense of needing to be locked. > > Oh, no, I'm sure it's okay. It just that it goes against the general advice > of never passing EO's across threads, only GIDs. I know it's okay in this > case because it's Apple internal, locking is handled elsewhere, and they are > generally just much smarter than me... > > Still, I cringe ;-) It's like a reflex. > > >>> It stands to reason that when the ec is saved, any eo in that ec should be >>> removed from the threadInfos. It sounds like the _ThreadInfo should set up >>> an observer on the ec's EditingContextDidSaveChangesNotification. Once >>> saved, any threadInfo with an eo in that ec should set >>> _lastWillChangeObject to null. >> >> I think you will find that the EC is already handing this. > > For the current thread only though, right? I could see how one thread might > edit EO1, thread2 edits EO2 related to EO1, Thread3 edits EO1 again and > finally saves the EC. You are gonna keep yourself up at night thinking things like that. > Now the EC sends notify(null) to the EOObserverCenter and clears the > ThreadInfo on thread3, but thread1 and 2 are unaware. If threadInfo set up a > notification then every threadInfo would be notified of the save and thread1 > and 2 would clear too. But threads 1 and 2 don't need to be aware as they are working with a different EC at that point. The problem is that the performance optimization is not getting reset at the correct time. > At least that's the way I read the problem description. > >> The issue arises when the EO is modified but NOT saved during the RR loop. >> What is missing in WO vs YellowBox is a fully built out concept of an event >> loop. There is no clear, common "event ended" for the RR loop where this >> would normally be set to null. There are notific
Re: Weird Behaviour...
On 2011-12-07, at 8:01 AM, Ramsey Gurley wrote: > > On Dec 6, 2011, at 3:43 PM, Chuck Hill wrote: > >> >> On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: >> >>> On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: >>> I can feel how uncomfortable you are. What makes me confused is to never see this bug before. It's hard to believe that nobody saw the errors if there are error. But on another side, I (and all the team) worked on many applications so following the explanation, I don't know why we don't see this issue much more often. >>> >>> I suspect the more prevalent use of concurrent requests these days has >>> exposed this bug. >> >> It is worth carefully reading over the reproduction steps: >> >>>* How it fails: A request is handled by WorkerThread0. By the end of >>> the request the eo has been modified but not saved, so the EOObserverCenter >>> remembers >>>* that WorkerThread0's most recent object is that eo. Fifteen more >>> requests are handled by WorkerThreads 1-15 in sequence. One of these >>> requests completes >>>* the modification of the eo and calls saveChanges on the ec. At >>> this point the ec tells the EOObserverCenter to forget about its most >>> recent object, but >>>* it's being set to null in WorkerThread14 or whatever, not >>> WorkerThread0. >>>* >>>* The next request will wrap around to to be handled by >>> WorkerThread0. This request modifies an attribute on the eo, but since the >>> EOObserverCenter still >>>* thinks WorkerThread0 has already noticed the eo, it ignores the >>> willChange and the ec doesn't grab a snapshot. >>>* >>>* Later in the processing of this request, a different object gets >>> changed, willChange gets called and the ec grabs a snapshot of the second >>> object. Then, >>>* a change gets made to the original eo, willChange gets called, and >>> since the EOObserverCenter was paying attention to the second object, it >>> goes ahead >>>* and notifies the ec about the first object. >>>* >>>* At this point the ec grabs a snapshot of the first object, but >>> it's too late -- the object has already been modified, the ec didn't know >>> about the >>>* previous change, so when saveChanges gets called the previous >>> changes don't get saved to the database. And now your object graph no >>> longer matches the >>>* database, and your app is borked. >> >> >> Note that it has to be the _same_ eo (same GID) and the same thread and it >> has to be in a modified but unsaved state. > > In EOObserverCenter I see: > > eo == threadInfo._lastWillChangeObject > > Same ec, multiple threads.. oy! Not sure what is concerning you there. _lastWillChangeObject is just a performance optimization to avoid sending repeat, identical notifications. I don't think it is getting used by two threads at once, at least not in the sense of needing to be locked. > It stands to reason that when the ec is saved, any eo in that ec should be > removed from the threadInfos. It sounds like the _ThreadInfo should set up > an observer on the ec's EditingContextDidSaveChangesNotification. Once > saved, any threadInfo with an eo in that ec should set _lastWillChangeObject > to null. I think you will find that the EC is already handing this. The issue arises when the EO is modified but NOT saved during the RR loop. What is missing in WO vs YellowBox is a fully built out concept of an event loop. There is no clear, common "event ended" for the RR loop where this would normally be set to null. There are notifications that could be caught. The end of dispatchRequest() is a reasonably good place to do this. > I wonder what about nested ECs? Let's say the parent ec is saved, but the > nested ec has changes to an EO already. What then? If it has changes, it has already gotten a "original snapshot" and has merged in the parent's saved changes. Also remember that the eo in the parent is not instance equal (==) to the eo in the child so EOObserverCenter sees them as totally different objects. Chuck >> My guess is that unless your users are doing highly concurrent editing of >> the same data that this will rarely affect you. That is why I found it >> fixing Calven's problem so readily a surprise. >> >> >> And a question regarding the workaround: is there any drawback to call the EOObserver in the dispatchRequest method like suggested? >>> >>> For multiple active worker threads, a good question... >>> >>> Lachlan Deck >>> lachlan.d...@gmail.com >>> >>> ___ >>> 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 >>> >>
Re: Weird Behaviour...
On Dec 7, 2011, at 2:30 PM, Chuck Hill wrote: > > On 2011-12-07, at 8:01 AM, Ramsey Gurley wrote: > >> >> On Dec 6, 2011, at 3:43 PM, Chuck Hill wrote: >> >>> >>> On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: >>> On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: > I can feel how uncomfortable you are. > > What makes me confused is to never see this bug before. It's hard to > believe that nobody saw the errors if there are error. But on another > side, I (and all the team) worked on many applications so following the > explanation, I don't know why we don't see this issue much more often. I suspect the more prevalent use of concurrent requests these days has exposed this bug. >>> >>> It is worth carefully reading over the reproduction steps: >>> * How it fails: A request is handled by WorkerThread0. By the end of the request the eo has been modified but not saved, so the EOObserverCenter remembers * that WorkerThread0's most recent object is that eo. Fifteen more requests are handled by WorkerThreads 1-15 in sequence. One of these requests completes * the modification of the eo and calls saveChanges on the ec. At this point the ec tells the EOObserverCenter to forget about its most recent object, but * it's being set to null in WorkerThread14 or whatever, not WorkerThread0. * * The next request will wrap around to to be handled by WorkerThread0. This request modifies an attribute on the eo, but since the EOObserverCenter still * thinks WorkerThread0 has already noticed the eo, it ignores the willChange and the ec doesn't grab a snapshot. * * Later in the processing of this request, a different object gets changed, willChange gets called and the ec grabs a snapshot of the second object. Then, * a change gets made to the original eo, willChange gets called, and since the EOObserverCenter was paying attention to the second object, it goes ahead * and notifies the ec about the first object. * * At this point the ec grabs a snapshot of the first object, but it's too late -- the object has already been modified, the ec didn't know about the * previous change, so when saveChanges gets called the previous changes don't get saved to the database. And now your object graph no longer matches the * database, and your app is borked. >>> >>> >>> Note that it has to be the _same_ eo (same GID) and the same thread and it >>> has to be in a modified but unsaved state. >> >> In EOObserverCenter I see: >> >> eo == threadInfo._lastWillChangeObject >> >> Same ec, multiple threads.. oy! > > Not sure what is concerning you there. _lastWillChangeObject is just a > performance optimization to avoid sending repeat, identical notifications. I > don't think it is getting used by two threads at once, at least not in the > sense of needing to be locked. Oh, no, I'm sure it's okay. It just that it goes against the general advice of never passing EO's across threads, only GIDs. I know it's okay in this case because it's Apple internal, locking is handled elsewhere, and they are generally just much smarter than me... Still, I cringe ;-) It's like a reflex. >> It stands to reason that when the ec is saved, any eo in that ec should be >> removed from the threadInfos. It sounds like the _ThreadInfo should set up >> an observer on the ec's EditingContextDidSaveChangesNotification. Once >> saved, any threadInfo with an eo in that ec should set _lastWillChangeObject >> to null. > > I think you will find that the EC is already handing this. For the current thread only though, right? I could see how one thread might edit EO1, thread2 edits EO2 related to EO1, Thread3 edits EO1 again and finally saves the EC. Now the EC sends notify(null) to the EOObserverCenter and clears the ThreadInfo on thread3, but thread1 and 2 are unaware. If threadInfo set up a notification then every threadInfo would be notified of the save and thread1 and 2 would clear too. At least that's the way I read the problem description. > The issue arises when the EO is modified but NOT saved during the RR loop. > What is missing in WO vs YellowBox is a fully built out concept of an event > loop. There is no clear, common "event ended" for the RR loop where this > would normally be set to null. There are notifications that could be caught. > The end of dispatchRequest() is a reasonably good place to do this. Okay, so I've got this and all 12 frames are modifying an EO from the defaultSessionEC ... :-D Maybe reimplementing EOObserverCenter is over-engineering the problem, but if I do any event driven stuff outside of the RR loop using... say ... websockets, I'll need to remember to
Re: Weird Behaviour...
On 2011-12-07, at 12:06 PM, Calven Eggert wrote: > It might be helpful to know that I've discovered that my application that was > having this problem allows the user to click on a record in a list to go to > an edit page. On the edit page there is a save button and when clicked the > page remains displayed. My other WO apps do not have this behaviour, the > save button returns the user to the list page and so far I have not found any > issues with data not being saved in the database. Does the editing page make any automated changes before the user initiates a save? I am thinking of something like setting a lastModified timestamp. That would make the problem much more prevalent. Chuck > This all seems to fit in with how the bug is described earlier from Phillippe > and Chuck's additional comment. (In my testing I was editing a record > hitting save and editing again immediately on the same page. After > approximately 7 saves in a row the problem arose. In any case, this is now > resolved with the suggested fix.) > > On 2011-12-07, at 11:01 AM, Ramsey Gurley wrote: > >> >> On Dec 6, 2011, at 3:43 PM, Chuck Hill wrote: >> >>> >>> On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: >>> On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: > I can feel how uncomfortable you are. > > What makes me confused is to never see this bug before. It's hard to > believe that nobody saw the errors if there are error. But on another > side, I (and all the team) worked on many applications so following the > explanation, I don't know why we don't see this issue much more often. I suspect the more prevalent use of concurrent requests these days has exposed this bug. >>> >>> It is worth carefully reading over the reproduction steps: >>> * How it fails: A request is handled by WorkerThread0. By the end of the request the eo has been modified but not saved, so the EOObserverCenter remembers * that WorkerThread0's most recent object is that eo. Fifteen more requests are handled by WorkerThreads 1-15 in sequence. One of these requests completes * the modification of the eo and calls saveChanges on the ec. At this point the ec tells the EOObserverCenter to forget about its most recent object, but * it's being set to null in WorkerThread14 or whatever, not WorkerThread0. * * The next request will wrap around to to be handled by WorkerThread0. This request modifies an attribute on the eo, but since the EOObserverCenter still * thinks WorkerThread0 has already noticed the eo, it ignores the willChange and the ec doesn't grab a snapshot. * * Later in the processing of this request, a different object gets changed, willChange gets called and the ec grabs a snapshot of the second object. Then, * a change gets made to the original eo, willChange gets called, and since the EOObserverCenter was paying attention to the second object, it goes ahead * and notifies the ec about the first object. * * At this point the ec grabs a snapshot of the first object, but it's too late -- the object has already been modified, the ec didn't know about the * previous change, so when saveChanges gets called the previous changes don't get saved to the database. And now your object graph no longer matches the * database, and your app is borked. >>> >>> >>> Note that it has to be the _same_ eo (same GID) and the same thread and it >>> has to be in a modified but unsaved state. >> >> In EOObserverCenter I see: >> >> eo == threadInfo._lastWillChangeObject >> >> Same ec, multiple threads.. oy! >> >> It stands to reason that when the ec is saved, any eo in that ec should be >> removed from the threadInfos. It sounds like the _ThreadInfo should set up >> an observer on the ec's EditingContextDidSaveChangesNotification. Once >> saved, any threadInfo with an eo in that ec should set _lastWillChangeObject >> to null. >> >> I wonder what about nested ECs? Let's say the parent ec is saved, but the >> nested ec has changes to an EO already. What then? >> >> >>> My guess is that unless your users are doing highly concurrent editing of >>> the same data that this will rarely affect you. That is why I found it >>> fixing Calven's problem so readily a surprise. >>> >>> >>> > And a question regarding the workaround: is there any drawback to call > the EOObserver in the dispatchRequest method like suggested? For multiple active worker threads, a good question... Lachlan Deck lachlan.d...@gmail.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (
Re: Weird Behaviour...
There have been other bugs in the past (and maybe still in 5.4.3) that can
cause the same symptoms. An unlocked EC can also result in this.
On 2011-12-07, at 1:02 PM, Andrew Lindesay wrote:
> Hi there;
>
> Yes I believe this actually is indicative of the problem; it seems that the
> editing context at that moment doesn't think it has any changes when it
> actually does.
>
> cheers.
>
> On 8/12/11 2:59 AM, ISHIMOTO Ken wrote:
>> Hi,
>>
>> Do you use
>>
>> ec.hasChanged() {
>>
>> ec.saveChanges();
>>
>> }
>>
>> I have found, but not find why sometimes hasChanged() says false but the
>> EO really changed.
>>
>>
>>
>>
>>
>> On 2011/12/05, at 15:35, Calven Eggert wrote:
>>
>>> Hi, All
>>>
>>> I'm having some weird behaviour and have spent the last weekend trying
>>> to figure out what is going on. Here is what's happening:
>>>
>>> I have an EO record that has a number of fields including foreign
>>> keys. I run the application on my machine or on a Mac Server and edit
>>> a record by changing field values, including selections in different
>>> popups to change the foreign key values. I verify that the changes
>>> have been made by using a SQL application called Froq App to look
>>> directly into the database.
>>>
>>> Now the weird thing is that sometimes the data is not changed in the
>>> database. I'll log out and then back into the app and make the exact
>>> same changes and this time it works. This completely scares me and now
>>> I have absolutely no faith in what the application is saving.
>>>
>>> Any one have any clues on why this might be happening and what I can
>>> do to figure this out. I'm completely stumped. :-(
>>>
>>> Calven
>>> ___
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com
>>> <mailto:Webobjects-dev@lists.apple.com>)
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/ken%40ksroom.com
>>>
>>> This email sent to k...@ksroom.com
>>
>>
>>
>> Thank you
>>
>> Ken Ishimoto
>>
>>
>> K's ROOM
>>
>> [E-Mail] mailto:k...@ksroom.com>>
>> [iChat:] mailto:ibase_...@mac.com>>
>> [HP] http://www.ksroom.com/
>> _
>> This e-mail has not been scanned for viruses because it was written on
>> an Mac,
>> and there are NO Viruses on an Apple Computer.
>> For further information visit http://www.apple.com
>>
>>
>>
>>
>>
>>
>> ___
>> 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/apl%40lindesay.co.nz
>>
>> This email sent to a...@lindesay.co.nz
>
>
> --
> Andrew Lindesay
> www.silvereye.co.nz
> ___
> 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
Practical WebObjects - for developers who want to increase their overall
knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
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
Re: Weird Behaviour...
Hi there;
Yes I believe this actually is indicative of the problem; it seems that
the editing context at that moment doesn't think it has any changes when
it actually does.
cheers.
On 8/12/11 2:59 AM, ISHIMOTO Ken wrote:
Hi,
Do you use
ec.hasChanged() {
ec.saveChanges();
}
I have found, but not find why sometimes hasChanged() says false but the
EO really changed.
On 2011/12/05, at 15:35, Calven Eggert wrote:
Hi, All
I'm having some weird behaviour and have spent the last weekend trying
to figure out what is going on. Here is what's happening:
I have an EO record that has a number of fields including foreign
keys. I run the application on my machine or on a Mac Server and edit
a record by changing field values, including selections in different
popups to change the foreign key values. I verify that the changes
have been made by using a SQL application called Froq App to look
directly into the database.
Now the weird thing is that sometimes the data is not changed in the
database. I'll log out and then back into the app and make the exact
same changes and this time it works. This completely scares me and now
I have absolutely no faith in what the application is saving.
Any one have any clues on why this might be happening and what I can
do to figure this out. I'm completely stumped. :-(
Calven
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com
<mailto:Webobjects-dev@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/ken%40ksroom.com
This email sent to k...@ksroom.com
Thank you
Ken Ishimoto
K's ROOM
[E-Mail] mailto:k...@ksroom.com>>
[iChat:] mailto:ibase_...@mac.com>>
[HP] http://www.ksroom.com/
_
This e-mail has not been scanned for viruses because it was written on
an Mac,
and there are NO Viruses on an Apple Computer.
For further information visit http://www.apple.com
___
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/apl%40lindesay.co.nz
This email sent to a...@lindesay.co.nz
--
Andrew Lindesay
www.silvereye.co.nz
___
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
Re: Weird Behaviour...
It might be helpful to know that I've discovered that my application that was having this problem allows the user to click on a record in a list to go to an edit page. On the edit page there is a save button and when clicked the page remains displayed. My other WO apps do not have this behaviour, the save button returns the user to the list page and so far I have not found any issues with data not being saved in the database. This all seems to fit in with how the bug is described earlier from Phillippe and Chuck's additional comment. (In my testing I was editing a record hitting save and editing again immediately on the same page. After approximately 7 saves in a row the problem arose. In any case, this is now resolved with the suggested fix.) On 2011-12-07, at 11:01 AM, Ramsey Gurley wrote: > > On Dec 6, 2011, at 3:43 PM, Chuck Hill wrote: > >> >> On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: >> >>> On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: >>> I can feel how uncomfortable you are. What makes me confused is to never see this bug before. It's hard to believe that nobody saw the errors if there are error. But on another side, I (and all the team) worked on many applications so following the explanation, I don't know why we don't see this issue much more often. >>> >>> I suspect the more prevalent use of concurrent requests these days has >>> exposed this bug. >> >> It is worth carefully reading over the reproduction steps: >> >>>* How it fails: A request is handled by WorkerThread0. By the end of >>> the request the eo has been modified but not saved, so the EOObserverCenter >>> remembers >>>* that WorkerThread0's most recent object is that eo. Fifteen more >>> requests are handled by WorkerThreads 1-15 in sequence. One of these >>> requests completes >>>* the modification of the eo and calls saveChanges on the ec. At >>> this point the ec tells the EOObserverCenter to forget about its most >>> recent object, but >>>* it's being set to null in WorkerThread14 or whatever, not >>> WorkerThread0. >>>* >>>* The next request will wrap around to to be handled by >>> WorkerThread0. This request modifies an attribute on the eo, but since the >>> EOObserverCenter still >>>* thinks WorkerThread0 has already noticed the eo, it ignores the >>> willChange and the ec doesn't grab a snapshot. >>>* >>>* Later in the processing of this request, a different object gets >>> changed, willChange gets called and the ec grabs a snapshot of the second >>> object. Then, >>>* a change gets made to the original eo, willChange gets called, and >>> since the EOObserverCenter was paying attention to the second object, it >>> goes ahead >>>* and notifies the ec about the first object. >>>* >>>* At this point the ec grabs a snapshot of the first object, but >>> it's too late -- the object has already been modified, the ec didn't know >>> about the >>>* previous change, so when saveChanges gets called the previous >>> changes don't get saved to the database. And now your object graph no >>> longer matches the >>>* database, and your app is borked. >> >> >> Note that it has to be the _same_ eo (same GID) and the same thread and it >> has to be in a modified but unsaved state. > > In EOObserverCenter I see: > > eo == threadInfo._lastWillChangeObject > > Same ec, multiple threads.. oy! > > It stands to reason that when the ec is saved, any eo in that ec should be > removed from the threadInfos. It sounds like the _ThreadInfo should set up > an observer on the ec's EditingContextDidSaveChangesNotification. Once > saved, any threadInfo with an eo in that ec should set _lastWillChangeObject > to null. > > I wonder what about nested ECs? Let's say the parent ec is saved, but the > nested ec has changes to an EO already. What then? > > >> My guess is that unless your users are doing highly concurrent editing of >> the same data that this will rarely affect you. That is why I found it >> fixing Calven's problem so readily a surprise. >> >> >> And a question regarding the workaround: is there any drawback to call the EOObserver in the dispatchRequest method like suggested? >>> >>> For multiple active worker threads, a good question... >>> >>> Lachlan Deck >>> lachlan.d...@gmail.com >>> >>> ___ >>> 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 >> >> Practical WebObjects - for developers who want to increase their overa
Re: Weird Behaviour...
On Dec 6, 2011, at 3:43 PM, Chuck Hill wrote: > > On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: > >> On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: >> >>> I can feel how uncomfortable you are. >>> >>> What makes me confused is to never see this bug before. It's hard to >>> believe that nobody saw the errors if there are error. But on another side, >>> I (and all the team) worked on many applications so following the >>> explanation, I don't know why we don't see this issue much more often. >> >> I suspect the more prevalent use of concurrent requests these days has >> exposed this bug. > > It is worth carefully reading over the reproduction steps: > >> * How it fails: A request is handled by WorkerThread0. By the end of >> the request the eo has been modified but not saved, so the EOObserverCenter >> remembers >> * that WorkerThread0's most recent object is that eo. Fifteen more >> requests are handled by WorkerThreads 1-15 in sequence. One of these >> requests completes >> * the modification of the eo and calls saveChanges on the ec. At >> this point the ec tells the EOObserverCenter to forget about its most recent >> object, but >> * it's being set to null in WorkerThread14 or whatever, not >> WorkerThread0. >> * >> * The next request will wrap around to to be handled by >> WorkerThread0. This request modifies an attribute on the eo, but since the >> EOObserverCenter still >> * thinks WorkerThread0 has already noticed the eo, it ignores the >> willChange and the ec doesn't grab a snapshot. >> * >> * Later in the processing of this request, a different object gets >> changed, willChange gets called and the ec grabs a snapshot of the second >> object. Then, >> * a change gets made to the original eo, willChange gets called, and >> since the EOObserverCenter was paying attention to the second object, it >> goes ahead >> * and notifies the ec about the first object. >> * >> * At this point the ec grabs a snapshot of the first object, but >> it's too late -- the object has already been modified, the ec didn't know >> about the >> * previous change, so when saveChanges gets called the previous >> changes don't get saved to the database. And now your object graph no longer >> matches the >> * database, and your app is borked. > > > Note that it has to be the _same_ eo (same GID) and the same thread and it > has to be in a modified but unsaved state. In EOObserverCenter I see: eo == threadInfo._lastWillChangeObject Same ec, multiple threads.. oy! It stands to reason that when the ec is saved, any eo in that ec should be removed from the threadInfos. It sounds like the _ThreadInfo should set up an observer on the ec's EditingContextDidSaveChangesNotification. Once saved, any threadInfo with an eo in that ec should set _lastWillChangeObject to null. I wonder what about nested ECs? Let's say the parent ec is saved, but the nested ec has changes to an EO already. What then? > My guess is that unless your users are doing highly concurrent editing of the > same data that this will rarely affect you. That is why I found it fixing > Calven's problem so readily a surprise. > > > >>> And a question regarding the workaround: is there any drawback to call the >>> EOObserver in the dispatchRequest method like suggested? >> >> For multiple active worker threads, a good question... >> >> Lachlan Deck >> lachlan.d...@gmail.com >> >> ___ >> 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 > > Practical WebObjects - for developers who want to increase their overall > knowledge of WebObjects or who are trying to solve specific problems. > http://www.global-village.net/products/practical_webobjects > > > > > > > > ___ > 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/ramseygurley%40gmail.com > > This email sent to ramseygur...@gmail.com 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
Re: Weird Behaviour...
I don't use ec.hasChanged().
On 2011-12-07, at 8:59 AM, ISHIMOTO Ken wrote:
> Hi,
>
> Do you use
>
> ec.hasChanged() {
>
> ec.saveChanges();
>
> }
>
> I have found, but not find why sometimes hasChanged() says false but the EO
> really changed.
>
>
>
>
>
> On 2011/12/05, at 15:35, Calven Eggert wrote:
>
>> Hi, All
>>
>> I'm having some weird behaviour and have spent the last weekend trying to
>> figure out what is going on. Here is what's happening:
>>
>> I have an EO record that has a number of fields including foreign keys. I
>> run the application on my machine or on a Mac Server and edit a record by
>> changing field values, including selections in different popups to change
>> the foreign key values. I verify that the changes have been made by using a
>> SQL application called Froq App to look directly into the database.
>>
>> Now the weird thing is that sometimes the data is not changed in the
>> database. I'll log out and then back into the app and make the exact same
>> changes and this time it works. This completely scares me and now I have
>> absolutely no faith in what the application is saving.
>>
>> Any one have any clues on why this might be happening and what I can do to
>> figure this out. I'm completely stumped. :-(
>>
>> Calven
>> ___
>> 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/ken%40ksroom.com
>>
>> This email sent to k...@ksroom.com
>
>
>
> Thank you
>
> Ken Ishimoto
>
>
> K's ROOM
>
> [E-Mail]
> [iChat:]
> [HP] http://www.ksroom.com/
> _
> This e-mail has not been scanned for viruses because it was written on an Mac,
> and there are NO Viruses on an Apple Computer.
> For further information visit http://www.apple.com
>
>
>
>
___
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
Re: Weird Behaviour...
Hi,
Do you use
ec.hasChanged() {
ec.saveChanges();
}
I have found, but not find why sometimes hasChanged() says false but the EO
really changed.
On 2011/12/05, at 15:35, Calven Eggert wrote:
> Hi, All
>
> I'm having some weird behaviour and have spent the last weekend trying to
> figure out what is going on. Here is what's happening:
>
> I have an EO record that has a number of fields including foreign keys. I run
> the application on my machine or on a Mac Server and edit a record by
> changing field values, including selections in different popups to change the
> foreign key values. I verify that the changes have been made by using a SQL
> application called Froq App to look directly into the database.
>
> Now the weird thing is that sometimes the data is not changed in the
> database. I'll log out and then back into the app and make the exact same
> changes and this time it works. This completely scares me and now I have
> absolutely no faith in what the application is saving.
>
> Any one have any clues on why this might be happening and what I can do to
> figure this out. I'm completely stumped. :-(
>
> Calven
> ___
> 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/ken%40ksroom.com
>
> This email sent to k...@ksroom.com
Thank you
Ken Ishimoto
K's ROOM
[E-Mail]
[iChat:]
[HP] http://www.ksroom.com/
_
This e-mail has not been scanned for viruses because it was written on an Mac,
and there are NO Viruses on an Apple Computer.
For further information visit http://www.apple.com
___
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
Re: Weird Behaviour...
I'm developing on a MacBookPro (2.53 Intel Core 2 Duo, Snow Leopard) and deploying on Mac Minis (2.66 GHz Intel Core 2 Duo, Leopard) WO 5.4.3. NOTE: As mentioned earlier in this thread, the bug seems to appear when many changes have been made to the same EO. I've managed to find a repeatable sequence that displays the behaviour of not saving some of the changes. Not sure if there is a shorter number of steps but and this point I don't have the time to look for one. What I do know is that there are many records in my database that have incorrect values in some of their fields and now that this bug is fixed I have the task of cleaning up the data. Luckily, from what I've found, there is too much data in the records instead of not enough and this is a problem much easier to solve than the other way around. If anyone wants further details let me know. On 2011-12-07, at 3:23 AM, Andrew Lindesay wrote: > Hello; > > I see a similar situation to Calven in the application I am working on and > have seen this in a development setting with one user. This is the first > time I think I have seen this and I have undertaken a number of projects over > the years without having done anything particularly radical. I don't (and > probably can't) understand what is happening, but adding that piece of code > seems to resolve the problem. > > I have to pause to wonder (not project wonder) to myself if there is > something going on at the platform level here. Calven; what are you > developing and deploying on? > > Regards; > > -- > Andrew Lindesay > www.silvereye.co.nz > ___ > 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/ceggert%40uhnresearch.ca > > This email sent to cegg...@uhnresearch.ca > ___ 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
Re: Weird Behaviour...
Hello; projects over the years without having done anything particularly radical. ^^^ I mean "particularly radical" (as in different) in this situation. Regards -- Andrew Lindesay www.silvereye.co.nz ___ 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
Re: Weird Behaviour...
Hello; I see a similar situation to Calven in the application I am working on and have seen this in a development setting with one user. This is the first time I think I have seen this and I have undertaken a number of projects over the years without having done anything particularly radical. I don't (and probably can't) understand what is happening, but adding that piece of code seems to resolve the problem. I have to pause to wonder (not project wonder) to myself if there is something going on at the platform level here. Calven; what are you developing and deploying on? Regards; -- Andrew Lindesay www.silvereye.co.nz ___ 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
Re: Weird Behaviour...
Hi Chuck, I like your answer :-) Any insight that could explain why we see this bug so rarely? Philippe Sent from my iPhone On 6 déc. 2011, at 23:45, Chuck Hill wrote: > > On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: > >> On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: > >>> And a question regarding the workaround: is there any drawback to call the >>> EOObserver in the dispatchRequest method like suggested? >> >> For multiple active worker threads, a good question... > > > This is all thread based, so the multiple worker threads does not matter. I > have used this for years now, no problems. > > > Chuck > > > -- > Chuck Hill Senior Consultant / VP Development > > Practical WebObjects - for developers who want to increase their overall > knowledge of WebObjects or who are trying to solve specific problems. > http://www.global-village.net/products/practical_webobjects > > > > > > > ___ 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
Re: Weird Behaviour...
On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: > On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: >> And a question regarding the workaround: is there any drawback to call the >> EOObserver in the dispatchRequest method like suggested? > > For multiple active worker threads, a good question... This is all thread based, so the multiple worker threads does not matter. I have used this for years now, no problems. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects 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
Re: Weird Behaviour...
On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: > On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: > >> I can feel how uncomfortable you are. >> >> What makes me confused is to never see this bug before. It's hard to believe >> that nobody saw the errors if there are error. But on another side, I (and >> all the team) worked on many applications so following the explanation, I >> don't know why we don't see this issue much more often. > > I suspect the more prevalent use of concurrent requests these days has > exposed this bug. It is worth carefully reading over the reproduction steps: > * How it fails: A request is handled by WorkerThread0. By the end of > the request the eo has been modified but not saved, so the EOObserverCenter > remembers > * that WorkerThread0's most recent object is that eo. Fifteen more > requests are handled by WorkerThreads 1-15 in sequence. One of these requests > completes > * the modification of the eo and calls saveChanges on the ec. At > this point the ec tells the EOObserverCenter to forget about its most recent > object, but > * it's being set to null in WorkerThread14 or whatever, not > WorkerThread0. > * > * The next request will wrap around to to be handled by > WorkerThread0. This request modifies an attribute on the eo, but since the > EOObserverCenter still > * thinks WorkerThread0 has already noticed the eo, it ignores the > willChange and the ec doesn't grab a snapshot. > * > * Later in the processing of this request, a different object gets > changed, willChange gets called and the ec grabs a snapshot of the second > object. Then, > * a change gets made to the original eo, willChange gets called, and > since the EOObserverCenter was paying attention to the second object, it goes > ahead > * and notifies the ec about the first object. > * > * At this point the ec grabs a snapshot of the first object, but > it's too late -- the object has already been modified, the ec didn't know > about the > * previous change, so when saveChanges gets called the previous > changes don't get saved to the database. And now your object graph no longer > matches the > * database, and your app is borked. Note that it has to be the _same_ eo (same GID) and the same thread and it has to be in a modified but unsaved state. My guess is that unless your users are doing highly concurrent editing of the same data that this will rarely affect you. That is why I found it fixing Calven's problem so readily a surprise. >> And a question regarding the workaround: is there any drawback to call the >> EOObserver in the dispatchRequest method like suggested? > > For multiple active worker threads, a good question... > > Lachlan Deck > lachlan.d...@gmail.com > > ___ > 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 Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects 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
Re: Weird Behaviour...
On 2011-12-06, at 2:15 PM, Lachlan Deck wrote: > On 07/12/2011, at 7:46 AM, Pascal Robert wrote: > >> Le 2011-12-06 à 15:44, Andrew Lindesay a écrit : >> >>> Hello Calven; >>> >>> Thanks, but I guess we should thank the original people who investigated! >>> >>> It would be nice if a dot release of WO could be done with a patch for >>> whatever problem this is because it's a bit of an uncomfortable bug. >> >> Sadly, I think the patch will either be in Wonder > > I don't think that's sad if the patch is in Wonder. It's sad only for those > not using Wonder. Not using Wonder is sad all by itself. > >> or in Cayenne... > > Cayenne is not a bug fix for EOF. It's an alternative. Both, of course, are > imperfect technologies, as with every technology :) > > Lachlan Deck > lachlan.d...@gmail.com > > ___ > 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 Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects 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
Re: Weird Behaviour...
On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: > I can feel how uncomfortable you are. > > What makes me confused is to never see this bug before. It's hard to believe > that nobody saw the errors if there are error. But on another side, I (and > all the team) worked on many applications so following the explanation, I > don't know why we don't see this issue much more often. I suspect the more prevalent use of concurrent requests these days has exposed this bug. > And a question regarding the workaround: is there any drawback to call the > EOObserver in the dispatchRequest method like suggested? For multiple active worker threads, a good question... Lachlan Deck lachlan.d...@gmail.com ___ 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
Re: Weird Behaviour...
On 07/12/2011, at 9:18 AM, prob...@macti.ca wrote: > Le 2011-12-06 à 17:15, "Lachlan Deck" a écrit : > >> On 07/12/2011, at 7:46 AM, Pascal Robert wrote: >> >>> Le 2011-12-06 à 15:44, Andrew Lindesay a écrit : >>> Hello Calven; Thanks, but I guess we should thank the original people who investigated! It would be nice if a dot release of WO could be done with a patch for whatever problem this is because it's a bit of an uncomfortable bug. >>> >>> Sadly, I think the patch will either be in Wonder >> >> I don't think that's sad if the patch is in Wonder. It's sad only for those >> not using Wonder. >> >>> or in Cayenne... >> >> Cayenne is not a bug fix for EOF. It's an alternative. Both, of course, are >> imperfect technologies, as with every technology :) > > At least Cayenne is updated and truly open source.., Sure. It's very good in that way. My point was, so is Wonder: 'updated and truly open source'. Lachlan Deck lachlan.d...@gmail.com ___ 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
Re: Weird Behaviour...
I can feel how uncomfortable you are.
What makes me confused is to never see this bug before. It's hard to believe
that nobody saw the errors if there are error. But on another side, I (and all
the team) worked on many applications so following the explanation, I don't
know why we don't see this issue much more often.
And a question regarding the workaround: is there any drawback to call the
EOObserver in the dispatchRequest method like suggested?
Philippe
Sent from my iPhone
On 6 déc. 2011, at 22:52, Calven Eggert wrote:
> uncomfortable doesn't begin to describe how I'm feeling. Now I question the
> data in our database for all of our WO applications. egad. I need a drink.
> while I'm at it I'll get one for the boss too.
>
> On 2011-12-06, at 3:44 PM, Andrew Lindesay wrote:
>
>> Hello Calven;
>>
>> Thanks, but I guess we should thank the original people who investigated!
>>
>> It would be nice if a dot release of WO could be done with a patch for
>> whatever problem this is because it's a bit of an uncomfortable bug.
>>
>> cheers.
>>
>> On 7/12/11 3:35 AM, Calven Eggert wrote:
>>> Andrew, THANK YOU, THANK YOU, THANK YOU!!!
>>>
>>> This was exactly what was happening in my case and by simply adding this:
>>>
>>>public WOResponse dispatchRequest(WORequest request) {
>>>EOObserverCenter.notifyObserversObjectWillChange(null);
>>>return super.dispatchRequest(request);
>>>}
>>>
>>> It completely solved my problems. No more sporadic saves are happening.
>>> wow! After a week I was really thinking I was going crazy.
>>>
>>> Thanks again and again.
>>>
>>> Calven
>>>
>>>
>>> On 2011-12-05, at 3:38 PM, Andrew Lindesay wrote:
>>>
>>>> Hi Calven;
>>>>
>>>> Somebody mentioned to me this posting;
>>>>
>>>> http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html
>>>>
>>>> We have seen a similar (unsettling) problem in a system which I am
>>>> involved in and this seems to have worked-around the problem for us.
>>>>
>>>> Regards;
>>>>
>>>> On 6/12/11 3:35 AM, Calven Eggert wrote:
>>>>> Hi, All
>>>>>
>>>>> I'm having some weird behaviour and have spent the last weekend trying to
>>>>> figure out what is going on. Here is what's happening:
>>>>>
>>>>> I have an EO record that has a number of fields including foreign keys. I
>>>>> run the application on my machine or on a Mac Server and edit a record by
>>>>> changing field values, including selections in different popups to change
>>>>> the foreign key values. I verify that the changes have been made by
>>>>> using a SQL application called Froq App to look directly into the
>>>>> database.
>>>>>
>>>>> Now the weird thing is that sometimes the data is not changed in the
>>>>> database. I'll log out and then back into the app and make the exact
>>>>> same changes and this time it works. This completely scares me and now I
>>>>> have absolutely no faith in what the application is saving.
>>>>>
>>>>> Any one have any clues on why this might be happening and what I can do
>>>>> to figure this out. I'm completely stumped. :-(
>>>>>
>>>>> Calven
>>>>> ___
>>>>> 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/apl%40lindesay.co.nz
>>>>>
>>>>> This email sent to a...@lindesay.co.nz
>>>>>
>>>>
>>>>
>>>> --
>>>> Andrew Lindesay
>>>> www.silvereye.co.nz
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Andrew Lindesay
>> www.silvereye.co.nz
>>
>
>
> ___
> 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/prabier%40me.com
>
> This email sent to prab...@me.com
___
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
Re: Weird Behaviour...
Envoyé de mon iPhone Le 2011-12-06 à 17:15, "Lachlan Deck" a écrit : > On 07/12/2011, at 7:46 AM, Pascal Robert wrote: > >> Le 2011-12-06 à 15:44, Andrew Lindesay a écrit : >> >>> Hello Calven; >>> >>> Thanks, but I guess we should thank the original people who investigated! >>> >>> It would be nice if a dot release of WO could be done with a patch for >>> whatever problem this is because it's a bit of an uncomfortable bug. >> >> Sadly, I think the patch will either be in Wonder > > I don't think that's sad if the patch is in Wonder. It's sad only for those > not using Wonder. > >> or in Cayenne... > > Cayenne is not a bug fix for EOF. It's an alternative. Both, of course, are > imperfect technologies, as with every technology :) At least Cayenne is updated and truly open source.., ___ 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
Re: Weird Behaviour...
On 07/12/2011, at 7:46 AM, Pascal Robert wrote: > Le 2011-12-06 à 15:44, Andrew Lindesay a écrit : > >> Hello Calven; >> >> Thanks, but I guess we should thank the original people who investigated! >> >> It would be nice if a dot release of WO could be done with a patch for >> whatever problem this is because it's a bit of an uncomfortable bug. > > Sadly, I think the patch will either be in Wonder I don't think that's sad if the patch is in Wonder. It's sad only for those not using Wonder. > or in Cayenne... Cayenne is not a bug fix for EOF. It's an alternative. Both, of course, are imperfect technologies, as with every technology :) Lachlan Deck lachlan.d...@gmail.com ___ 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
Re: Weird Behaviour...
I expect that in most cases it would be rather rare that this caused problems.
I am surprised that adding this so immediately resolved your problem.
On 2011-12-06, at 1:52 PM, Calven Eggert wrote:
> uncomfortable doesn't begin to describe how I'm feeling. Now I question the
> data in our database for all of our WO applications. egad. I need a drink.
> while I'm at it I'll get one for the boss too.
>
> On 2011-12-06, at 3:44 PM, Andrew Lindesay wrote:
>
>> Hello Calven;
>>
>> Thanks, but I guess we should thank the original people who investigated!
>>
>> It would be nice if a dot release of WO could be done with a patch for
>> whatever problem this is because it's a bit of an uncomfortable bug.
>>
>> cheers.
>>
>> On 7/12/11 3:35 AM, Calven Eggert wrote:
>>> Andrew, THANK YOU, THANK YOU, THANK YOU!!!
>>>
>>> This was exactly what was happening in my case and by simply adding this:
>>>
>>>public WOResponse dispatchRequest(WORequest request) {
>>> EOObserverCenter.notifyObserversObjectWillChange(null);
>>> return super.dispatchRequest(request);
>>>}
>>>
>>> It completely solved my problems. No more sporadic saves are happening.
>>> wow! After a week I was really thinking I was going crazy.
>>>
>>> Thanks again and again.
>>>
>>> Calven
>>>
>>>
>>> On 2011-12-05, at 3:38 PM, Andrew Lindesay wrote:
>>>
>>>> Hi Calven;
>>>>
>>>> Somebody mentioned to me this posting;
>>>>
>>>> http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html
>>>>
>>>> We have seen a similar (unsettling) problem in a system which I am
>>>> involved in and this seems to have worked-around the problem for us.
>>>>
>>>> Regards;
>>>>
>>>> On 6/12/11 3:35 AM, Calven Eggert wrote:
>>>>> Hi, All
>>>>>
>>>>> I'm having some weird behaviour and have spent the last weekend trying to
>>>>> figure out what is going on. Here is what's happening:
>>>>>
>>>>> I have an EO record that has a number of fields including foreign keys. I
>>>>> run the application on my machine or on a Mac Server and edit a record by
>>>>> changing field values, including selections in different popups to change
>>>>> the foreign key values. I verify that the changes have been made by
>>>>> using a SQL application called Froq App to look directly into the
>>>>> database.
>>>>>
>>>>> Now the weird thing is that sometimes the data is not changed in the
>>>>> database. I'll log out and then back into the app and make the exact
>>>>> same changes and this time it works. This completely scares me and now I
>>>>> have absolutely no faith in what the application is saving.
>>>>>
>>>>> Any one have any clues on why this might be happening and what I can do
>>>>> to figure this out. I'm completely stumped. :-(
>>>>>
>>>>> Calven
>>>>> ___
>>>>> 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/apl%40lindesay.co.nz
>>>>>
>>>>> This email sent to a...@lindesay.co.nz
>>>>>
>>>>
>>>>
>>>> --
>>>> Andrew Lindesay
>>>> www.silvereye.co.nz
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Andrew Lindesay
>> www.silvereye.co.nz
>>
>
>
> ___
> 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
Practical WebObjects - for developers who want to increase their overall
knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
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
Re: Weird Behaviour...
uncomfortable doesn't begin to describe how I'm feeling. Now I question the
data in our database for all of our WO applications. egad. I need a drink.
while I'm at it I'll get one for the boss too.
On 2011-12-06, at 3:44 PM, Andrew Lindesay wrote:
> Hello Calven;
>
> Thanks, but I guess we should thank the original people who investigated!
>
> It would be nice if a dot release of WO could be done with a patch for
> whatever problem this is because it's a bit of an uncomfortable bug.
>
> cheers.
>
> On 7/12/11 3:35 AM, Calven Eggert wrote:
>> Andrew, THANK YOU, THANK YOU, THANK YOU!!!
>>
>> This was exactly what was happening in my case and by simply adding this:
>>
>> public WOResponse dispatchRequest(WORequest request) {
>> EOObserverCenter.notifyObserversObjectWillChange(null);
>> return super.dispatchRequest(request);
>> }
>>
>> It completely solved my problems. No more sporadic saves are happening.
>> wow! After a week I was really thinking I was going crazy.
>>
>> Thanks again and again.
>>
>> Calven
>>
>>
>> On 2011-12-05, at 3:38 PM, Andrew Lindesay wrote:
>>
>>> Hi Calven;
>>>
>>> Somebody mentioned to me this posting;
>>>
>>> http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html
>>>
>>> We have seen a similar (unsettling) problem in a system which I am involved
>>> in and this seems to have worked-around the problem for us.
>>>
>>> Regards;
>>>
>>> On 6/12/11 3:35 AM, Calven Eggert wrote:
>>>> Hi, All
>>>>
>>>> I'm having some weird behaviour and have spent the last weekend trying to
>>>> figure out what is going on. Here is what's happening:
>>>>
>>>> I have an EO record that has a number of fields including foreign keys. I
>>>> run the application on my machine or on a Mac Server and edit a record by
>>>> changing field values, including selections in different popups to change
>>>> the foreign key values. I verify that the changes have been made by using
>>>> a SQL application called Froq App to look directly into the database.
>>>>
>>>> Now the weird thing is that sometimes the data is not changed in the
>>>> database. I'll log out and then back into the app and make the exact same
>>>> changes and this time it works. This completely scares me and now I have
>>>> absolutely no faith in what the application is saving.
>>>>
>>>> Any one have any clues on why this might be happening and what I can do to
>>>> figure this out. I'm completely stumped. :-(
>>>>
>>>> Calven
>>>> ___
>>>> 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/apl%40lindesay.co.nz
>>>>
>>>> This email sent to a...@lindesay.co.nz
>>>>
>>>
>>>
>>> --
>>> Andrew Lindesay
>>> www.silvereye.co.nz
>>>
>>
>>
>>
>
>
> --
> Andrew Lindesay
> www.silvereye.co.nz
>
___
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
Re: Weird Behaviour...
Le 2011-12-06 à 15:44, Andrew Lindesay a écrit :
> Hello Calven;
>
> Thanks, but I guess we should thank the original people who investigated!
>
> It would be nice if a dot release of WO could be done with a patch for
> whatever problem this is because it's a bit of an uncomfortable bug.
Sadly, I think the patch will either be in Wonder or in Cayenne...
> cheers.
>
> On 7/12/11 3:35 AM, Calven Eggert wrote:
>> Andrew, THANK YOU, THANK YOU, THANK YOU!!!
>>
>> This was exactly what was happening in my case and by simply adding this:
>>
>> public WOResponse dispatchRequest(WORequest request) {
>> EOObserverCenter.notifyObserversObjectWillChange(null);
>> return super.dispatchRequest(request);
>> }
>>
>> It completely solved my problems. No more sporadic saves are happening.
>> wow! After a week I was really thinking I was going crazy.
>>
>> Thanks again and again.
>>
>> Calven
>>
>>
>> On 2011-12-05, at 3:38 PM, Andrew Lindesay wrote:
>>
>>> Hi Calven;
>>>
>>> Somebody mentioned to me this posting;
>>>
>>> http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html
>>>
>>> We have seen a similar (unsettling) problem in a system which I am involved
>>> in and this seems to have worked-around the problem for us.
>>>
>>> Regards;
>>>
>>> On 6/12/11 3:35 AM, Calven Eggert wrote:
>>>> Hi, All
>>>>
>>>> I'm having some weird behaviour and have spent the last weekend trying to
>>>> figure out what is going on. Here is what's happening:
>>>>
>>>> I have an EO record that has a number of fields including foreign keys. I
>>>> run the application on my machine or on a Mac Server and edit a record by
>>>> changing field values, including selections in different popups to change
>>>> the foreign key values. I verify that the changes have been made by using
>>>> a SQL application called Froq App to look directly into the database.
>>>>
>>>> Now the weird thing is that sometimes the data is not changed in the
>>>> database. I'll log out and then back into the app and make the exact same
>>>> changes and this time it works. This completely scares me and now I have
>>>> absolutely no faith in what the application is saving.
>>>>
>>>> Any one have any clues on why this might be happening and what I can do to
>>>> figure this out. I'm completely stumped. :-(
>>>>
>>>> Calven
>>>> ___
>>>> 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/apl%40lindesay.co.nz
>>>>
>>>> This email sent to a...@lindesay.co.nz
>>>>
>>>
>>>
>>> --
>>> Andrew Lindesay
>>> www.silvereye.co.nz
>>>
>>
>>
>>
>
>
> --
> Andrew Lindesay
> www.silvereye.co.nz
> ___
> 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/probert%40macti.ca
>
> This email sent to prob...@macti.ca
___
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
Re: Weird Behaviour...
Hello Calven;
Thanks, but I guess we should thank the original people who investigated!
It would be nice if a dot release of WO could be done with a patch for
whatever problem this is because it's a bit of an uncomfortable bug.
cheers.
On 7/12/11 3:35 AM, Calven Eggert wrote:
Andrew, THANK YOU, THANK YOU, THANK YOU!!!
This was exactly what was happening in my case and by simply adding this:
public WOResponse dispatchRequest(WORequest request) {
EOObserverCenter.notifyObserversObjectWillChange(null);
return super.dispatchRequest(request);
}
It completely solved my problems. No more sporadic saves are happening. wow!
After a week I was really thinking I was going crazy.
Thanks again and again.
Calven
On 2011-12-05, at 3:38 PM, Andrew Lindesay wrote:
Hi Calven;
Somebody mentioned to me this posting;
http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html
We have seen a similar (unsettling) problem in a system which I am involved in
and this seems to have worked-around the problem for us.
Regards;
On 6/12/11 3:35 AM, Calven Eggert wrote:
Hi, All
I'm having some weird behaviour and have spent the last weekend trying to
figure out what is going on. Here is what's happening:
I have an EO record that has a number of fields including foreign keys. I run
the application on my machine or on a Mac Server and edit a record by changing
field values, including selections in different popups to change the foreign
key values. I verify that the changes have been made by using a SQL
application called Froq App to look directly into the database.
Now the weird thing is that sometimes the data is not changed in the database.
I'll log out and then back into the app and make the exact same changes and
this time it works. This completely scares me and now I have absolutely no
faith in what the application is saving.
Any one have any clues on why this might be happening and what I can do to
figure this out. I'm completely stumped. :-(
Calven
___
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/apl%40lindesay.co.nz
This email sent to a...@lindesay.co.nz
--
Andrew Lindesay
www.silvereye.co.nz
--
Andrew Lindesay
www.silvereye.co.nz
___
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
Re: Weird Behaviour...
It is not fixed in Wonder that I see.
On 2011-12-06, at 7:44 AM, Alexander Spohr wrote:
> Hm, should we all put that in our apps then?
> Or is it fixed in 5.4 or Wonder?
>
>
>
> Am 06.12.2011 um 15:35 schrieb Calven Eggert:
>
>> Andrew, THANK YOU, THANK YOU, THANK YOU!!!
>>
>> This was exactly what was happening in my case and by simply adding this:
>>
>> public WOResponse dispatchRequest(WORequest request) {
>> EOObserverCenter.notifyObserversObjectWillChange(null);
>> return super.dispatchRequest(request);
>> }
>>
>> It completely solved my problems. No more sporadic saves are happening.
>> wow! After a week I was really thinking I was going crazy.
>>
>> Thanks again and again.
>>
>> Calven
>>
>>
>> On 2011-12-05, at 3:38 PM, Andrew Lindesay wrote:
>>
>>> Hi Calven;
>>>
>>> Somebody mentioned to me this posting;
>>>
>>> http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html
>>>
>>> We have seen a similar (unsettling) problem in a system which I am involved
>>> in and this seems to have worked-around the problem for us.
>>>
>>> Regards;
>>>
>>> On 6/12/11 3:35 AM, Calven Eggert wrote:
>>>> Hi, All
>>>>
>>>> I'm having some weird behaviour and have spent the last weekend trying to
>>>> figure out what is going on. Here is what's happening:
>>>>
>>>> I have an EO record that has a number of fields including foreign keys. I
>>>> run the application on my machine or on a Mac Server and edit a record by
>>>> changing field values, including selections in different popups to change
>>>> the foreign key values. I verify that the changes have been made by using
>>>> a SQL application called Froq App to look directly into the database.
>>>>
>>>> Now the weird thing is that sometimes the data is not changed in the
>>>> database. I'll log out and then back into the app and make the exact same
>>>> changes and this time it works. This completely scares me and now I have
>>>> absolutely no faith in what the application is saving.
>>>>
>>>> Any one have any clues on why this might be happening and what I can do to
>>>> figure this out. I'm completely stumped. :-(
>>>>
>>>> Calven
>>>> ___
>>>> 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/apl%40lindesay.co.nz
>>>>
>>>> This email sent to a...@lindesay.co.nz
>>>>
>>>
>>>
>>> --
>>> Andrew Lindesay
>>> www.silvereye.co.nz
>>>
>>
>>
>> ___
>> 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/atze%40freeport.de
>>
>> This email sent to a...@freeport.de
>
> ___
> 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
Practical WebObjects - for developers who want to increase their overall
knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
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
Re: Weird Behaviour...
I'm using WO 5.4.3 so that means it's not fixed there. I'm going to add to all
my projects. (I don't use Wonder)
Calven
On 2011-12-06, at 10:44 AM, Alexander Spohr wrote:
> Hm, should we all put that in our apps then?
> Or is it fixed in 5.4 or Wonder?
>
>
>
> Am 06.12.2011 um 15:35 schrieb Calven Eggert:
>
>> Andrew, THANK YOU, THANK YOU, THANK YOU!!!
>>
>> This was exactly what was happening in my case and by simply adding this:
>>
>> public WOResponse dispatchRequest(WORequest request) {
>> EOObserverCenter.notifyObserversObjectWillChange(null);
>> return super.dispatchRequest(request);
>> }
>>
>> It completely solved my problems. No more sporadic saves are happening.
>> wow! After a week I was really thinking I was going crazy.
>>
>> Thanks again and again.
>>
>> Calven
>>
>>
>> On 2011-12-05, at 3:38 PM, Andrew Lindesay wrote:
>>
>>> Hi Calven;
>>>
>>> Somebody mentioned to me this posting;
>>>
>>> http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html
>>>
>>> We have seen a similar (unsettling) problem in a system which I am involved
>>> in and this seems to have worked-around the problem for us.
>>>
>>> Regards;
>>>
>>> On 6/12/11 3:35 AM, Calven Eggert wrote:
>>>> Hi, All
>>>>
>>>> I'm having some weird behaviour and have spent the last weekend trying to
>>>> figure out what is going on. Here is what's happening:
>>>>
>>>> I have an EO record that has a number of fields including foreign keys. I
>>>> run the application on my machine or on a Mac Server and edit a record by
>>>> changing field values, including selections in different popups to change
>>>> the foreign key values. I verify that the changes have been made by using
>>>> a SQL application called Froq App to look directly into the database.
>>>>
>>>> Now the weird thing is that sometimes the data is not changed in the
>>>> database. I'll log out and then back into the app and make the exact same
>>>> changes and this time it works. This completely scares me and now I have
>>>> absolutely no faith in what the application is saving.
>>>>
>>>> Any one have any clues on why this might be happening and what I can do to
>>>> figure this out. I'm completely stumped. :-(
>>>>
>>>> Calven
>>>> ___
>>>> 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/apl%40lindesay.co.nz
>>>>
>>>> This email sent to a...@lindesay.co.nz
>>>>
>>>
>>>
>>> --
>>> Andrew Lindesay
>>> www.silvereye.co.nz
>>>
>>
>>
>> ___
>> 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/atze%40freeport.de
>>
>> This email sent to a...@freeport.de
>
>
>
___
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
Re: Weird Behaviour...
Hm, should we all put that in our apps then?
Or is it fixed in 5.4 or Wonder?
Am 06.12.2011 um 15:35 schrieb Calven Eggert:
> Andrew, THANK YOU, THANK YOU, THANK YOU!!!
>
> This was exactly what was happening in my case and by simply adding this:
>
>public WOResponse dispatchRequest(WORequest request) {
> EOObserverCenter.notifyObserversObjectWillChange(null);
> return super.dispatchRequest(request);
>}
>
> It completely solved my problems. No more sporadic saves are happening.
> wow! After a week I was really thinking I was going crazy.
>
> Thanks again and again.
>
> Calven
>
>
> On 2011-12-05, at 3:38 PM, Andrew Lindesay wrote:
>
>> Hi Calven;
>>
>> Somebody mentioned to me this posting;
>>
>> http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html
>>
>> We have seen a similar (unsettling) problem in a system which I am involved
>> in and this seems to have worked-around the problem for us.
>>
>> Regards;
>>
>> On 6/12/11 3:35 AM, Calven Eggert wrote:
>>> Hi, All
>>>
>>> I'm having some weird behaviour and have spent the last weekend trying to
>>> figure out what is going on. Here is what's happening:
>>>
>>> I have an EO record that has a number of fields including foreign keys. I
>>> run the application on my machine or on a Mac Server and edit a record by
>>> changing field values, including selections in different popups to change
>>> the foreign key values. I verify that the changes have been made by using
>>> a SQL application called Froq App to look directly into the database.
>>>
>>> Now the weird thing is that sometimes the data is not changed in the
>>> database. I'll log out and then back into the app and make the exact same
>>> changes and this time it works. This completely scares me and now I have
>>> absolutely no faith in what the application is saving.
>>>
>>> Any one have any clues on why this might be happening and what I can do to
>>> figure this out. I'm completely stumped. :-(
>>>
>>> Calven
>>> ___
>>> 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/apl%40lindesay.co.nz
>>>
>>> This email sent to a...@lindesay.co.nz
>>>
>>
>>
>> --
>> Andrew Lindesay
>> www.silvereye.co.nz
>>
>
>
> ___
> 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/atze%40freeport.de
>
> This email sent to a...@freeport.de
___
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
Re: Weird Behaviour...
Andrew, THANK YOU, THANK YOU, THANK YOU!!!
This was exactly what was happening in my case and by simply adding this:
public WOResponse dispatchRequest(WORequest request) {
EOObserverCenter.notifyObserversObjectWillChange(null);
return super.dispatchRequest(request);
}
It completely solved my problems. No more sporadic saves are happening. wow!
After a week I was really thinking I was going crazy.
Thanks again and again.
Calven
On 2011-12-05, at 3:38 PM, Andrew Lindesay wrote:
> Hi Calven;
>
> Somebody mentioned to me this posting;
>
> http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html
>
> We have seen a similar (unsettling) problem in a system which I am involved
> in and this seems to have worked-around the problem for us.
>
> Regards;
>
> On 6/12/11 3:35 AM, Calven Eggert wrote:
>> Hi, All
>>
>> I'm having some weird behaviour and have spent the last weekend trying to
>> figure out what is going on. Here is what's happening:
>>
>> I have an EO record that has a number of fields including foreign keys. I
>> run the application on my machine or on a Mac Server and edit a record by
>> changing field values, including selections in different popups to change
>> the foreign key values. I verify that the changes have been made by using a
>> SQL application called Froq App to look directly into the database.
>>
>> Now the weird thing is that sometimes the data is not changed in the
>> database. I'll log out and then back into the app and make the exact same
>> changes and this time it works. This completely scares me and now I have
>> absolutely no faith in what the application is saving.
>>
>> Any one have any clues on why this might be happening and what I can do to
>> figure this out. I'm completely stumped. :-(
>>
>> Calven
>> ___
>> 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/apl%40lindesay.co.nz
>>
>> This email sent to a...@lindesay.co.nz
>>
>
>
> --
> Andrew Lindesay
> www.silvereye.co.nz
>
___
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
Re: Weird Behaviour...
Yes! Thanks so much for pointing this out because it sounds like I'm having the exact same problem. 99% of the time things work fine. And I'm saving the same EO each time. I can't wait to get to work in the morning to see if this solution solves my problem. :-) On 2011-12-05, at 3:38 PM, Andrew Lindesay wrote: > Hi Calven; > > Somebody mentioned to me this posting; > > http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html > > We have seen a similar (unsettling) problem in a system which I am involved > in and this seems to have worked-around the problem for us. > > Regards; > > On 6/12/11 3:35 AM, Calven Eggert wrote: >> Hi, All >> >> I'm having some weird behaviour and have spent the last weekend trying to >> figure out what is going on. Here is what's happening: >> >> I have an EO record that has a number of fields including foreign keys. I >> run the application on my machine or on a Mac Server and edit a record by >> changing field values, including selections in different popups to change >> the foreign key values. I verify that the changes have been made by using a >> SQL application called Froq App to look directly into the database. >> >> Now the weird thing is that sometimes the data is not changed in the >> database. I'll log out and then back into the app and make the exact same >> changes and this time it works. This completely scares me and now I have >> absolutely no faith in what the application is saving. >> >> Any one have any clues on why this might be happening and what I can do to >> figure this out. I'm completely stumped. :-( >> >> Calven >> ___ >> 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/apl%40lindesay.co.nz >> >> This email sent to a...@lindesay.co.nz >> > > > -- > Andrew Lindesay > www.silvereye.co.nz > ___ 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
Re: Weird Behaviour...
Wow. That's an excellent post. It may well explain some of the problems I remember seeing. Was there a fix for this put into Wonder or something? On 06/12/2011, at 7:38 AM, Andrew Lindesay wrote: > Hi Calven; > > Somebody mentioned to me this posting; > > http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html > > We have seen a similar (unsettling) problem in a system which I am involved > in and this seems to have worked-around the problem for us. Lachlan Deck lachlan.d...@gmail.com ___ 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
Re: Weird Behaviour...
Hi Calven; Somebody mentioned to me this posting; http://www.mail-archive.com/webobjects-dev@lists.apple.com/msg25391.html We have seen a similar (unsettling) problem in a system which I am involved in and this seems to have worked-around the problem for us. Regards; On 6/12/11 3:35 AM, Calven Eggert wrote: Hi, All I'm having some weird behaviour and have spent the last weekend trying to figure out what is going on. Here is what's happening: I have an EO record that has a number of fields including foreign keys. I run the application on my machine or on a Mac Server and edit a record by changing field values, including selections in different popups to change the foreign key values. I verify that the changes have been made by using a SQL application called Froq App to look directly into the database. Now the weird thing is that sometimes the data is not changed in the database. I'll log out and then back into the app and make the exact same changes and this time it works. This completely scares me and now I have absolutely no faith in what the application is saving. Any one have any clues on why this might be happening and what I can do to figure this out. I'm completely stumped. :-( Calven ___ 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/apl%40lindesay.co.nz This email sent to a...@lindesay.co.nz -- Andrew Lindesay www.silvereye.co.nz ___ 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
Re: Weird Behaviour...
Primary key and one foreign key field. On 2011-12-05, at 12:45 PM, Alexander Spohr wrote: > How is your optimistic locking set up? > Anything else than the primary key? > > atze > > ___ 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
Re: Weird Behaviour...
That sounds like you are violating one or more of the EOF Commandments. In particular, I would suspect using unlocked editing contexts. Chuck On 2011-12-05, at 6:35 AM, Calven Eggert wrote: > Hi, All > > I'm having some weird behaviour and have spent the last weekend trying to > figure out what is going on. Here is what's happening: > > I have an EO record that has a number of fields including foreign keys. I run > the application on my machine or on a Mac Server and edit a record by > changing field values, including selections in different popups to change the > foreign key values. I verify that the changes have been made by using a SQL > application called Froq App to look directly into the database. > > Now the weird thing is that sometimes the data is not changed in the > database. I'll log out and then back into the app and make the exact same > changes and this time it works. This completely scares me and now I have > absolutely no faith in what the application is saving. > > Any one have any clues on why this might be happening and what I can do to > figure this out. I'm completely stumped. :-( > > Calven > ___ > 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 Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects 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
Re: Weird Behaviour...
Logging is your friend here - log out the value of editingContext.updatedObjects and see if it is empty. On Mon, Dec 5, 2011 at 12:21 PM, John Huss wrote: > If you have a save button, then do it in that action at the end. > > > On Mon, Dec 5, 2011 at 9:16 AM, Calven Eggert wrote: > >> When do you suggest that I call objectWillChange(eo)? >> >> >> On 2011-12-05, at 10:07 AM, John Huss wrote: >> >> It is possible that EOF doesn't think the objects have changed and so it >> doesn't actually save anything. If so, calling >> editingContext.objectWillChange(eo) will force it to look at the object and >> see if it has changes. >> >> John >> >> On Mon, Dec 5, 2011 at 8:35 AM, Calven Eggert wrote: >> >>> Hi, All >>> >>> I'm having some weird behaviour and have spent the last weekend trying >>> to figure out what is going on. Here is what's happening: >>> >>> I have an EO record that has a number of fields including foreign keys. >>> I run the application on my machine or on a Mac Server and edit a record by >>> changing field values, including selections in different popups to change >>> the foreign key values. I verify that the changes have been made by using >>> a SQL application called Froq App to look directly into the database. >>> >>> Now the weird thing is that sometimes the data is not changed in the >>> database. I'll log out and then back into the app and make the exact same >>> changes and this time it works. This completely scares me and now I have >>> absolutely no faith in what the application is saving. >>> >>> Any one have any clues on why this might be happening and what I can do >>> to figure this out. I'm completely stumped. :-( >>> >>> Calven >>> ___ >>> 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 >>> >> >> >> > ___ 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
Re: Weird Behaviour...
If you have a save button, then do it in that action at the end. On Mon, Dec 5, 2011 at 9:16 AM, Calven Eggert wrote: > When do you suggest that I call objectWillChange(eo)? > > > On 2011-12-05, at 10:07 AM, John Huss wrote: > > It is possible that EOF doesn't think the objects have changed and so it > doesn't actually save anything. If so, calling > editingContext.objectWillChange(eo) will force it to look at the object and > see if it has changes. > > John > > On Mon, Dec 5, 2011 at 8:35 AM, Calven Eggert wrote: > >> Hi, All >> >> I'm having some weird behaviour and have spent the last weekend trying to >> figure out what is going on. Here is what's happening: >> >> I have an EO record that has a number of fields including foreign keys. I >> run the application on my machine or on a Mac Server and edit a record by >> changing field values, including selections in different popups to change >> the foreign key values. I verify that the changes have been made by using >> a SQL application called Froq App to look directly into the database. >> >> Now the weird thing is that sometimes the data is not changed in the >> database. I'll log out and then back into the app and make the exact same >> changes and this time it works. This completely scares me and now I have >> absolutely no faith in what the application is saving. >> >> Any one have any clues on why this might be happening and what I can do >> to figure this out. I'm completely stumped. :-( >> >> Calven >> ___ >> 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 >> > > > ___ 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
Re: Weird Behaviour...
How is your optimistic locking set up? Anything else than the primary key? atze ___ 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
Re: Weird Behaviour...
These aren't new EOs. On 2011-12-05, at 10:45 AM, Ruenagel, Frank wrote: > Hi, > > typically this is a result of a free-floating EO not included in any EC. > > Use EOUtilities.createAndInsertInstance(ec, "myNewEntitiesName"); > > See: http://en.wikibooks.org/wiki/WebObjects/Database_Development > > Switch on Database logging to see what EOF does: > > NSLog.allowDebugLoggingForGroups(NSLog.DebugGroupDatabaseAccess); > > > Regards > Frank > > > > -Ursprüngliche Nachricht- > Von: webobjects-dev-bounces+webobjects=symposion...@lists.apple.com > [mailto:webobjects-dev-bounces+webobjects=symposion...@lists.apple.com] Im > Auftrag von Calven Eggert > Bereitgestellt: Montag, 5. Dezember 2011 15:35 > Bereitgestellt in: WebObjects > Unterhaltung: Weird Behaviour... > Betreff: Weird Behaviour... > > Hi, All > > I'm having some weird behaviour and have spent the last weekend trying to > figure out what is going on. Here is what's happening: > > I have an EO record that has a number of fields including foreign keys. I run > the application on my machine or on a Mac Server and edit a record by > changing field values, including selections in different popups to change the > foreign key values. I verify that the changes have been made by using a SQL > application called Froq App to look directly into the database. > > Now the weird thing is that sometimes the data is not changed in the > database. I'll log out and then back into the app and make the exact same > changes and this time it works. This completely scares me and now I have > absolutely no faith in what the application is saving. > > Any one have any clues on why this might be happening and what I can do to > figure this out. I'm completely stumped. :-( > > Calven > ___ > 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/webobjects%40symposion.de > > This email sent to webobje...@symposion.de > > ___ 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
AW: Weird Behaviour...
Hi, typically this is a result of a free-floating EO not included in any EC. Use EOUtilities.createAndInsertInstance(ec, "myNewEntitiesName"); See: http://en.wikibooks.org/wiki/WebObjects/Database_Development Switch on Database logging to see what EOF does: NSLog.allowDebugLoggingForGroups(NSLog.DebugGroupDatabaseAccess); Regards Frank -Ursprüngliche Nachricht- Von: webobjects-dev-bounces+webobjects=symposion...@lists.apple.com [mailto:webobjects-dev-bounces+webobjects=symposion...@lists.apple.com] Im Auftrag von Calven Eggert Bereitgestellt: Montag, 5. Dezember 2011 15:35 Bereitgestellt in: WebObjects Unterhaltung: Weird Behaviour... Betreff: Weird Behaviour... Hi, All I'm having some weird behaviour and have spent the last weekend trying to figure out what is going on. Here is what's happening: I have an EO record that has a number of fields including foreign keys. I run the application on my machine or on a Mac Server and edit a record by changing field values, including selections in different popups to change the foreign key values. I verify that the changes have been made by using a SQL application called Froq App to look directly into the database. Now the weird thing is that sometimes the data is not changed in the database. I'll log out and then back into the app and make the exact same changes and this time it works. This completely scares me and now I have absolutely no faith in what the application is saving. Any one have any clues on why this might be happening and what I can do to figure this out. I'm completely stumped. :-( Calven ___ 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/webobjects%40symposion.de This email sent to webobje...@symposion.de ___ 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
Re: Weird Behaviour...
When do you suggest that I call objectWillChange(eo)? On 2011-12-05, at 10:07 AM, John Huss wrote: > It is possible that EOF doesn't think the objects have changed and so it > doesn't actually save anything. If so, calling > editingContext.objectWillChange(eo) will force it to look at the object and > see if it has changes. > > John > > On Mon, Dec 5, 2011 at 8:35 AM, Calven Eggert wrote: > Hi, All > > I'm having some weird behaviour and have spent the last weekend trying to > figure out what is going on. Here is what's happening: > > I have an EO record that has a number of fields including foreign keys. I run > the application on my machine or on a Mac Server and edit a record by > changing field values, including selections in different popups to change the > foreign key values. I verify that the changes have been made by using a SQL > application called Froq App to look directly into the database. > > Now the weird thing is that sometimes the data is not changed in the > database. I'll log out and then back into the app and make the exact same > changes and this time it works. This completely scares me and now I have > absolutely no faith in what the application is saving. > > Any one have any clues on why this might be happening and what I can do to > figure this out. I'm completely stumped. :-( > > Calven > ___ > 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 > ___ 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
Re: Weird Behaviour...
It is possible that EOF doesn't think the objects have changed and so it doesn't actually save anything. If so, calling editingContext.objectWillChange(eo) will force it to look at the object and see if it has changes. John On Mon, Dec 5, 2011 at 8:35 AM, Calven Eggert wrote: > Hi, All > > I'm having some weird behaviour and have spent the last weekend trying to > figure out what is going on. Here is what's happening: > > I have an EO record that has a number of fields including foreign keys. I > run the application on my machine or on a Mac Server and edit a record by > changing field values, including selections in different popups to change > the foreign key values. I verify that the changes have been made by using > a SQL application called Froq App to look directly into the database. > > Now the weird thing is that sometimes the data is not changed in the > database. I'll log out and then back into the app and make the exact same > changes and this time it works. This completely scares me and now I have > absolutely no faith in what the application is saving. > > Any one have any clues on why this might be happening and what I can do to > figure this out. I'm completely stumped. :-( > > Calven > ___ > 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 > ___ 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
Weird Behaviour...
Hi, All I'm having some weird behaviour and have spent the last weekend trying to figure out what is going on. Here is what's happening: I have an EO record that has a number of fields including foreign keys. I run the application on my machine or on a Mac Server and edit a record by changing field values, including selections in different popups to change the foreign key values. I verify that the changes have been made by using a SQL application called Froq App to look directly into the database. Now the weird thing is that sometimes the data is not changed in the database. I'll log out and then back into the app and make the exact same changes and this time it works. This completely scares me and now I have absolutely no faith in what the application is saving. Any one have any clues on why this might be happening and what I can do to figure this out. I'm completely stumped. :-( Calven ___ 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
