Re: Problem with nested editing contexts
Re: Problem with nested editing contexts
- Subject: Re: Problem with nested editing contexts
- From: Ken Anderson <email@hidden>
- Date: Mon, 26 Mar 2007 13:21:31 -0400
Steven,
If you were getting null pointers on your to-many relationships, you
are most likely overriding awakeFromInsertion without calling super
on that entity.
Ken
On Mar 26, 2007, at 1:09 PM, Steven Mark McCraw wrote:
Hi Chuck,
As it turns out, I was abusing EOF (although not in a way that has
ever been documented by Apple, to my knowledge). In my EOModeler
generation template, I was initializing all of the the to-many
relationships to empty (but non-null) arrays in the generated
constructor to avoid null pointer exceptions all over the place
(and/or to avoid having to write lots of code to check that the
relationships were non-null). I took the following steps:
a) started using EOGenerator
b) updated my EOGenerator templates so that the generated code
checks for null in the to-many relationship accessors and returns
an empty array if it is null
Lo and behold, that fixed the problem. It's frustrating to me that
there are so many gotchas in the framework that make it break in
very basic places and that have never, ever been documented by
Apple (to my knowledge), so much to the point that I have come very
close to just giving up WebObjects development all together. But
I'm feeling a lot better recently thanks to the support of people
like yourself and (what seems to be) a helpful growing user
community containing people like the project wonder guys. I feel
like WebObjects is once again becoming a good useable, viable
development platform in spite of Apple's loathsome lack of support
for the product, because of a user community that is taking up the
slack. Thanks!
Mark
On Mar 26, 2007, at 12:53 PM, Chuck Hill wrote:
On Mar 24, 2007, at 9:37 PM, Steven Mark McCraw wrote:
Hi Chuck,
That's was a good thought, and actually I was not locking the
child EC. It still strikes me as bizarre that the responsibility
of locking and unlocking the editing context is left up to the
programmer, but that's just me griping.
I am not sure what the original rationale for not providing
something at the WOSession level to manage more editing contexts.
Also, it looks from the output like ERXEC is getting used
(although I haven't done anything explicitly other than importing
the project wonder frameworks and subclassing ERXApplication and
ERXSession). Isn't that supposed to do automatic locking/
unlocking for you, or is there something I need to add? Could
ERXEC be part of the problem? I modified my code by adding a
nestedEC.lock() before the saveChanges, and a nestedEC.unlock()
after, but to no avail. I still got the same behavior. Any
other thoughts about what I might be doing wrong? It seems like
such a simple thing I'm trying to do...
I trust you have seen Mike's message on this.
Alternately, is there any workaround other than storing attribute
values in local instance variables which are then just copied
into the EO itself right before the save is committed? Would it
really be such a terrible idea just to not insert the EO into an
editing context until you know you're ready to save?
A very terrible idea. Unless, of course, you want to spend even
more quality debugging time with your app. ;-)
I keep reading things that say that this is a terrible idea, but
I've actually been doing it for years with no apparent problems.
We call that luck.
But because of all the posts, etc. that say it's a bad idea,
I'm trying to use the nested EC technique, but quite literally
getting nowhere doing even simple things with it. Any advice on
what approach I should take?
There is no need for a workaround. Somehow, somewhere, you are
abusing EOF. Even if you work around this, EOF will just lie in
wait and take its revenge elsewhere. I used nested editing
contexts. I know lots of others do too. They work just fine if
you play nice with EOF.
Chuck
On Mar 24, 2007, at 6:00 PM, Chuck Hill wrote:
Are you locking the child EC?
On Mar 24, 2007, at 2:30 PM, Steven Mark McCraw wrote:
Hi all,
I have recently bumped into a problem with using nested editing
contexts to accomplish add/edit workflows. What I'm doing
seems simple enough, and correct from my understanding of the
documentation. I'm creating a nested editing context:
EOEditingContext nestedEC = new EOEditingContext
(session.defaultEditingContext);
and then creating my EOs in this. When it's time to save, I do
the following:
nestedEC.saveChanges();
session.defaultEditingContext().saveChanges();
This seems to work fine with newly created items. The problem
comes when I try to do that on an item that has been modified.
I have printed out a few things within the code to confirm
this: when the nested editing context saves its changes, it's
supposed to push them into its parent context (or so I
thought), but this is definitely not happening. Is this a well
known issue? Has anyone seen this before? Am I missing
something? A couple of hours of googling turned up nothing for
me. The code and its output is shown below.
Thanks in advance for any help.
NSLog.out.appendln("nestedEC updatedObjects: " +
nestedEC.updatedObjects());
NSLog.out.appendln("nestedEC.parent: " +
nestedEC.parentObjectStore());
NSLog.out.appendln("session.defaultEditingContext: " +
session.defaultEditingContext());
nestedEC.saveChanges();
NSLog.out.appendln("session.defaultEditingContext
updatedObjects: " + session.defaultEditingContext
().updatedObjects());
session.defaultEditingContext().saveChanges();
The output is:
nestedEC updatedObjects: (Test, 380.00, null)
nestedEC.parent: er.extensions.ERXEC@ad81d2
session.defaultEditingContext: er.extensions.ERXEC@ad81d2
session.defaultEditingContext updatedObjects: ()
The first line shows that there is an updated object in the
nested EC
The second and third lines show that the ec is actually nested
within another
editing context and that the nested ec's parent is the
session's default editingContext
The fourth line shows that after calling saveChanges() in the
nested ec, the parent ec still is showing no objects to update
Consequently, if I check the database after calling the final
saveChanges, my change is not there.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com
This email sent to email@hidden
_______________________________________________
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