Re: Child Editing Contexts -- locking/unlocking
Re: Child Editing Contexts -- locking/unlocking
- Subject: Re: Child Editing Contexts -- locking/unlocking
- From: Dana Kashubeck <email@hidden>
- Date: Thu, 04 Aug 2005 12:17:30 -0400
Chuck Hill wrote:
Some additions to David's comments:
On Aug 4, 2005, at 8:59 AM, David LeBer wrote:
On 4-Aug-05, at 11:47 AM, Dana Kashubeck wrote:
I'm sorry if this is noise, but I've never worked with anything but
the defaultEditingContext before and I want to make absolutely sure
that I'm doing The Right Thing here.
I'm working on a wizard-like interface that resides in a
framework. The user may be creating several new EO's that they
decide at the end they don't want. Therefore, I don't want to put
them in the defaultEditingContext when they are created because I
don't want any changes to make their way there and get saved
accidentally on some other page (all of our WO apps use
defaultEditingContext exclusively).
Perhaps not the best plan WRT memory usage / session size.
I was a bit concerned about that . . . planned to see what sort of
memory footprint I run into.
I figured this is a perfect place for a child editing context.
I'd be looking more at a peer EC, possibly with a child EC for each
page of the wizard if you need to revert just what is on that page
without affecting the changes made on other pages.
Can I still fault in objects from the defaultEditingContext? The reason
I ask is that the WOSession subclass that we use has several methods
that grab information from the database using the
defaultEditingContext. I'd really like to not rewrite that subclass. I
would need to fault into the peer editing context some objects that I've
obtained from the session. Can I do this or should I just do my own
fetch and not use the session's methods?
Now, as long as I don't perform any sort of fetches or changes on
EOs, etc. in the init method, I can simply lock the child editing
context in each component's awake method and then unlock it in the
corresponding sleep method, right?
No, there are pitfalls in that approach. See Practical WebObjects 83
- 93 or the list archives.
I thought I had read that chapter correctly, but I will re-read it. Thanks.
--
-------------------------------------
Dana Kashubeck
Systems Manager
Riemer Reporting Service Inc.
http://www.riemer.com
Phone: 440-835-2477 x. 125
Fax: 440-835-4594
-------------------------------------
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
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