RE: saveChanges() not saving
RE: saveChanges() not saving
- Subject: RE: saveChanges() not saving
- From: "David Haggerty" <email@hidden>
- Date: Thu, 1 Mar 2007 14:52:58 -0500
- Thread-topic: saveChanges() not saving
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
_______________________________________________
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