Thanks... You were right I didn't dig far enough. One of the other programmers was setting values in the constructor of one of the parent classes of EmailCommunicationRecipient. I didn't go high enough up in the hierachy.
I will refer to the commandments from now on when troublshooting an issue like this. Thanks so much for the guidance! David -----Original Message----- From: Chuck Hill [mailto:[EMAIL PROTECTED] Sent: Thursday, March 01, 2007 2:57 PM To: David Haggerty Cc: Jerry W. Walker; [email protected] Subject: Re: saveChanges() not saving (a) Review the commandments (b) The cause of the error may be far away (in terms of both time and code) from the symptom you are seeing while saving. Don't just focus locally. Chuck On Mar 1, 2007, at 11:52 AM, David Haggerty wrote: > I over simplified the example... I was trying to remove some of our > internal stuff and I left out the locking. > > Same problem still occurs with the locking. > > EOEditingContext ec = new EOEditingContext(); try { > ec.lock(); > // If I uncomment this, it saves properly. > // ec.committedSnapshotForObject(ecr); > EmailCommunicationRecipient ecr = (EmailCommunicationRecipient) > EOUtilities.faultWithPrimaryKeyValue(ec, > "EmailCommunicationRecipient", new Integer(11312312)); > ecr.setDateSent(new NSTimestamp()); > ec.saveChanges(); > } finally { > ec.unlock(); > } > > Actually, in the original code I use our own EOEditingContext that > inherits from ERXEC. Is it bad to rely on ERXEC doing the > autolocking? > > -----Original Message----- > From: Chuck Hill [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 01, 2007 1:54 PM > To: Jerry W. Walker > Cc: David Haggerty; [email protected] > Subject: Re: saveChanges() not saving > > No, I only had the regular size of stone tablet. Four commandments > and I ran out of room. Obviously, Moses shopped at Costco. > > I supposed this could be considered a commandment, but it more falls > under locking. > > Chuck > > > > On Mar 1, 2007, at 10:50 AM, Jerry W. Walker wrote: > >> Hi, Chuck, >> >> That's interesting. I went to the EOF commandments page and couldn't >> find the commandment: >> >> * Don't do anything with a newly created Editing Context until >> you've locked it and be sure to unlock it at the end of your use, or >> at the end of your R-R cycle. (Don't worry about the WOSession's >> defaultEditingContext since WOSession locks it for the entire >> session.) >> >> Didn't that use to be in there? >> >> Regards, >> Jerry >> >> On Mar 1, 2007, at 1:25 PM, Chuck Hill wrote: >> >>> David, >>> >>> In at least one place in your code you are abusing EOF. This makes >>> EOF very cranky and, in return, it messes with your head. >>> Play nice and your problems will go away. :-) >>> >>> First, check very carefully that you are not violating one of the >>> EOF > >>> Commandments: >>> http://en.wikibooks.org/wiki/Programming:WebObjects/EOF/Using_EOF/ >>> The_EOF_Commandments >>> >>> Please don't respond that you are violating one of them and it is >>> just fine, because that is quite obviously not true. I mention this >>> because this is often the first response of commandment violators. >>> Thou shalt not. Really. :-) >>> >>> Next, enable NSLog.DebugGroupMultithreading and run through the app. > >>> Look for exception traces in the log that indicate unlocked access. >>> Unlocked access is like playing Russian Roulette with one empty >>> chamber. Fix them. >>> >>> >>> Chuck >>> >>> >>> >>> On Mar 1, 2007, at 9:40 AM, David Haggerty wrote: >>> >>>> I have come across a rather strange problem. Changes to an EO are >>>> not saving properly. In memory it shows that I have changed the EO >>>> but when I look at the editingContext, it doesn't show it in >>>> _unprocessedChanges. It also doesn't save the change that I am >>>> making. I finally realized that if I call >>>> ec.committedSnapshotForObject(ecr); BEFORE I make any changes to >>>> the object, it works fine. >>>> >>>> Here's an example of the code: >>>> >>>> EOEditingContext ec = new EOEditingContext(); >>>> // If I uncomment this, it saves properly. >>>> // ec.committedSnapshotForObject(ecr); >>>> EmailCommunicationRecipient ecr = (EmailCommunicationRecipient) >>>> EOUtilities.faultWithPrimaryKeyValue(ec, >>>> "EmailCommunicationRecipient", new Integer(11312312)); >>>> ecr.setDateSent(new NSTimestamp()); ec.saveChanges(); >>>> >>>> Strangely, if I do the following, the dateSent won't save but the >>>> status will: >>>> >>>> EOEditingContext ec = new EOEditingContext(); >>>> EmailCommunicationRecipient ecr = (EmailCommunicationRecipient) >>>> EOUtilities.faultWithPrimaryKeyValue(ec, >>>> "EmailCommunicationRecipient", new Integer(11312312)); >>>> ecr.setDateSent(new NSTimestamp()); >>>> ec.committedSnapshotForObject(ecr); >>>> addObjectToBothSidesOfRelationshipWithKey(aValue, >>>> "toCurrentStatus"); >>>> ec.saveChanges(); >>>> >>>> The only thing special with EMailCommunicationRecipient is that it >>>> is a single table inhertance in the model. >>>> >>>> EMailCommunicationRecipient extends CommunicationRecipient which >>>> extends AbstractCommunicationRecipient. >>>> >>>> Until I figure out what's going on, I was going to just add the >>>> following (because I just don't know how many places this is >>>> happening). Will this add much overhead?: >>>> >>>> public void awakeFromFetch(EOEditingContext ec){ >>>> super.awakeFromFetch(ec); >>>> ec.committedSnapshotForObject(ecr); >>>> } >>>> >>>> Thanks, >>>> David >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/chill% >>>> 40global-village.net >>>> >>>> This email sent to [EMAIL PROTECTED] >>> >>> -- >>> >>> 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 ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/jerrywwalker% >>> 40gmail.com >>> >>> This email sent to [EMAIL PROTECTED] >> >> >> -- >> __ Jerry W. Walker, >> WebObjects Developer/Instructor for High Performance Industrial >> Strength Internet Enabled Systems >> >> [EMAIL PROTECTED] >> 203 278-4085 office >> >> >> >> > > -- > > 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 > > > > > > -- 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 ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
