Re: Strange Core Data save behaviour ("required relationship nil"... when it is set the line before saving)
Re: Strange Core Data save behaviour ("required relationship nil"... when it is set the line before saving)
- Subject: Re: Strange Core Data save behaviour ("required relationship nil"... when it is set the line before saving)
- From: Ben Trumbull <email@hidden>
- Date: Wed, 30 Sep 2009 15:41:17 -0400
On Sep 30, 2009, at 12:56 AM, Luke Evans wrote:
Well, I'm more than happy to file a bug, as it has been tricky to
figure out (and I would probably still be at it without your
interjection).
There are several ways to frame the problem of course: it could be a
documentation bug... things aren't as simple as might first appear
in the docs/guide, or maybe something can be done to have deleted
object behave in a 'friendlier' manner w.r.t. their defunct
relationships. I suppose I can just find a general form of words
and let you good folks figure out what it really means in practice :-)
Probably some of both.
I still think I might have something more to figure out here too.
At the end of my testing, as an experiment I had a main thread timer
fire periodically to perform a save on the main thread's MOC
(without performing any changes on the main thread's MOC at all).
This induced the same problem, and I'm still curious as to how the
main thread's copy of the graph might have the nil in the
relationship under these conditions. AFAICS there shouldn't have
been any chance for either MOC to be in this condition at any time.
I assume the merge operation from the other thread is 'atomic'
somehow and activity on another thread (like a save) should not be
able to catch that MOC in some kind of in-between state?
merge ? I'm not sure I have a full grasp on your work flow here. If
you call mergeChangesFromContextDidSaveNotification, then that can
obviously make changes to the object graph.
There are two other issues in play. First, if you've set a merge
policy, then the MOC may pull in changes necessary to make the save
correct (e.g. implement and correct an optimistic locking failure).
Second, firing a timer on the main thread is totally non-deterministic
with respect to anything else on the main thread. The application
event loop is rather amorphously defined, so timers can fire either
inside or outside the main thread's current event's undo grouping.
Timers are intrinsically very unpredictable.
Aside from this 'stress' test though, I haven't (yet) got it to fall
over - essentially under the conditions where only one thread
(albeit one of several threads on any occasion) is making changes
and saving at a time.
I'm not sure I understand this last comment. Do you have threads
sharing a MOC ? Because threads with their own MOCs can make their
own changes and own saves simultaneously.
- Ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden