Re: Can't modify EO objects! ARGH! =(
Re: Can't modify EO objects! ARGH! =(
- Subject: Re: Can't modify EO objects! ARGH! =(
- From: Jonathan Rochkind <email@hidden>
- Date: Mon, 21 Jul 2003 11:04:35 -0500
There is an Apple document on using nested EC's to deal with exactly the
sort of thing we are talking about here. My current thinking matches
Chuck's on this though: it's probably better to use peer ECs rather than
nested ECs for this purpose. While the Apple document reccomends nested
ECs (wrongly, in my current opinion), the techniques and code examples they
give generally are right for peer ECs as well. The only difference is in
how you create the EC, naturally. [If you DO choose to use nested ECs, the
Apple document for some reason warns you against 'doubly' nesting them. In
fact, this warning is unneccesary---you CAN doubly nest ECs, if you really
mean to. But you probably don't really mean to. And again, I think peer
rather than nested ECs are generally the way to go.]
Alas, the document doesn't exist in the current documentation. But you can
find it in the old documentation at:
http://developer.apple.com/documentation/WebObjects/WebObjects_5/Topics/ProgrammingTopics.39.html
At 10:04 PM 7/20/2003 -0700, Chuck Hill wrote:
I've never tried this for this reason, but... :-) Try calling
ec.processRecentChanges() before calling saveChanges(). That may avoid the
validation errors. In either case I'd report this as a bug.
You might also want to consider peer (new EOEditingContext()) editing
contexts rather than nested. They are easier to setup and save. Nested
are usually only worth it if you are doing a multi page progress, IMO.
Chuck
At 01:29 PM 21/07/2003 +1000, Marek Wawrzyczny wrote:
>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
>
>
--
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.
_______________________________________________
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.