On Jun 5, 2008, at 4:37 PM, Ben Trumbull wrote:
On Jun 3, 2008, at 8:15 PM, Michael Link wrote:
Is there a reason you're not using Core Data's -
mergeChangesFromContextDidSaveNotification: ?
If the object is modified (inserted, update, or deleted), you
should pass in YES to -refreshObject:mergeChanges:
Actually I am using mergeChangesFromContextDidSaveNotification:, I
am calling refreshObject:mergeChanges: with NO on the
NSUpdatedObjectsKey objects just before as this avoids the problem
of Bug 5937572.
You shouldn't call -refreshObject:mergeChanges:NO on an object with
changes (passing YES is okay). The reason for this is if the object
is deleted or inserted, nuking that state is just plain weird. The
graph of objects will not behave they way you would wish. A nuked
inserted object is stuck in limbo, and a nuked deleted object can be
a stale pointer for any of the objects related to it across inverse
relationships. Nuking an updated object also has a high probability
of corrupting the relationship state for other objects with
relationships to it.
Since the objects on the main thread aren't supposed to have
changes, skipping the changed ones shouldn't be a burden.
I should skip using -refreshObject:mergeChanges:NO on any object that
is in NSUpdatedObjectsKey? Even though they don't have changes on the
main thread? I suppose that makes sense, the original reason for doing
this was to find a work-around for bug-5937572, which seems to work in
experimentation (although now without lazy controllers). I'm probably
just coding myself in a corner I don't want to be in anyways by doing
this. Ideally I would like to simply use
mergeChangesFromContextDidSaveNotification: although the merge seems
to produce the previously mentioned inconsistencies. I even tried
using -refreshObject:mergeChanges:YES, objectWithID:, and
deleteObject: to emulate what
mergeChangesFromContextDidSaveNotification: probably does on the
userInfo of the notification, but it produced the exact same results
to no surprise.
At this point we can now look at ObjectA (which is the same as
ObjectB except it is owned by the main thread's MOC) which will
show that it has 10 friends. It should have 20 but the merge has
deleted the 10 friends that were just inserted on the background
thread, but just for ObjectA. Looking at those 10 objects that were
deleted on the main thread you will find that they are still
friends with ObjectA. This leaves the object graph in an
inconsistent state.
The object on the main thread seems to think it has local changes to
the "friends" relationship and during the merge this is trumping the
changes you've just made in the other context. I'm still
investigating the issue with the new example.
That makes sense. Although I wasn't able to see any changes with the
public methods available to NSManagedObject, I'll assume that's
happening somewhere private.
I attached the Bug-2 project to bug-5989987 in Bug Reporter which may
help in the investigation. Also here: http://www.dazys.com/Bug-2.zip
--
Michael
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
