Re: Can't modify EO objects! ARGH! =(
Re: Can't modify EO objects! ARGH! =(
- Subject: Re: Can't modify EO objects! ARGH! =(
- From: Chuck Hill <email@hidden>
- Date: Fri, 18 Jul 2003 09:16:55 -0700
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.