Re: Can't modify EO objects! ARGH! =(
Re: Can't modify EO objects! ARGH! =(
- Subject: Re: Can't modify EO objects! ARGH! =(
- From: Marek Wawrzyczny <email@hidden>
- Date: Mon, 21 Jul 2003 13:29:22 +1000
There is one annoying side effect (at least in WO 5.1) which makes
1) create
2) insert
3) populate
rule annoying - when you use the default editing context and have to
insert then delete newly created objects frequently, prior to calling
saveChanges().
It appears, at least for us, that these "temporary" EOs hang around and
have their validate for save methods called when changes are being
committed. Testing seems to show that these objects don't actually get
committed to the database but the saving process results in validation
errors. Not critical but annoying.
I will be implementing nested editing contexts but nested editing
contexts are new to me and besides, I did not anticipate the current
behaviour.
On Saturday, Jul 19, 2003, at 02:16 Australia/Sydney, Chuck Hill wrote:
Ben,
When I was younger, I used to ride my motorcycle through red lights.
Just
for fun. I never got hit, but that does not mean it was not very
dangerous
(OK, and very stupid too).
You are playing a similar game. Regardless of what you are changing,
relationships or attributes, notifications are getting sent around EOF
when
it has no editing context to make sense of them. This results in
problems
at the snapshot layer. You probably won't see it right away, perhaps
not
until that next process you add to your application when out of the
blue
things stop working in a predictable manner. Perhaps, if you only
ever use
the default editing context in the session, you will never see
problems at
all.
Just don't think that it is safe. It's not.
Chuck
At 09:23 AM 18/07/2003 +0100, Ben Ketteridge wrote:
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
--
Chuck Hill email@hidden
Global Village Consulting Inc.
http://www.global-village.net
_______________________________________________
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.
Marek Wawrzyczny
software engineer
-------------------------->
ish group pty ltd
7 Darghan St Glebe 2037 Australia
phone +61 2 9660 1400 fax +61 2 9660 7400
http www.ish.com.au | email email@hidden
_______________________________________________
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.