Re: Can't modify EO objects! ARGH! =(
Re: Can't modify EO objects! ARGH! =(
- Subject: Re: Can't modify EO objects! ARGH! =(
- From: Ben Ketteridge <email@hidden>
- Date: Fri, 18 Jul 2003 09:23:37 +0100
Chuck Hill wrote:
Art Isbell wrote:
On Thursday, July 17, 2003, at 11:59 AM, Albert Jagnow wrote:
I am confused by the pattern you list below. I have had more problems
doing insert before populate.
Us too. We have found that a useful compromise is:
1) create
2) populate non-relationship columns
3) insert
4) populate relationships (mostly by addObjectToBothSidesOfRelationshipWithKey)
5) save
In this case, 3) _must_ come before 4) or else you get an NPE in the
addObject... call, but we get away with serious difficulty doing 2) before 3).
As Chuck stated, these problems can be dealt with by making the
changes in an editing context whose parent is the session's default
editing context. If you decide not to save these changes, set this
editing context to null so it is garbage collected. The session's
default editing context won't realize any changes have been made.
And if the user just hits the 'X' to kill the window without making a 'forget
it' request to the application, you're left with objects hanging around in the
child EC. In fact this can be a problem if you use the defaultEditingContext
and insert before you're ready to save!
Another possibly less flexible approach is to use just the default
editing context. If you make changes that you don't want to save,
send the editing context a revert() message.
As a slight variant, call session().defaultEditingContext().revert()
before starting a new set of changes. Either way, a little less elegant
than you might care for.
This is not available to the programmer of a multi-window web-app (like us),
as the user might have unsaved changes pending in one window (some of our
transactions _have_ to take multiple submits before a consistent save can be
made), so you can't just revert the EC at the start of a new page.
EOF knows what SQL to generate based on the changes made to
objects in an editing context. When you make changes to an object
that's not in an editing context, then EOF can't possibly know what
SQL to generate to apply these changes to the DB. You can get lucky
by making changes that don't affect the SQL generated, but you can
also get unlucky such that the changes that you have made won't get
saved to the DB.
We've never seen this in 4.5, 5.1 or 5.2. New objects (in the insertedObjects
list at saveChanges time) are assumed to have changed completely, so the whole
thing goes into the SQL. Existing objects (that change) are already in the EC
because you fetched them that way, so the EC gets it right anyway.
We definitely have a bit of a love-hate relationship with this area of EOF,
but we struggle on :)
--
Kind Regards
Ben.
Dr Ben Ketteridge
email@hidden
PME Product Manager,
ProAct International,
PO Box 100, Denbigh, UK.
Tel: 01745 817161 ext. 330
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.