RE: saveChanges() not saving
RE: saveChanges() not saving
- Subject: RE: saveChanges() not saving
- From: "David Haggerty" <email@hidden>
- Date: Thu, 1 Mar 2007 15:29:58 -0500
- Thread-topic: saveChanges() not saving
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@hidden]
Sent: Thursday, March 01, 2007 2:57 PM
To: David Haggerty
Cc: Jerry W. Walker; email@hidden
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@hidden]
> Sent: Thursday, March 01, 2007 1:54 PM
> To: Jerry W. Walker
> Cc: David Haggerty; email@hidden
> 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@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> 40global-village.net
>>>>
>>>> This email sent to email@hidden
>>>
>>> --
>>>
>>> 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@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> 40gmail.com
>>>
>>> This email sent to email@hidden
>>
>>
>> --
>> __ Jerry W. Walker,
>> WebObjects Developer/Instructor for High Performance Industrial
>> Strength Internet Enabled Systems
>>
>> email@hidden
>> 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden