Re: Undo in conjunction with core data
Re: Undo in conjunction with core data
- Subject: Re: Undo in conjunction with core data
- From: Kenneth Baxter <email@hidden>
- Date: Sun, 23 Jan 2011 08:56:30 +0000 (GMT)
On 23 Jan, 2011,at 12:45 PM, Dave Fernandes <email@hidden> wrote:
Looking back at my code, I see that I just use the KVO message to know that something changed. I then re-traverse the data model to update the view. (Not the most scalable technique.)
I thought I would try that same approach. There is something unusual though - if I add a child, it shows up in the array controller and the children, and if I manually delete it, it is deleted from the array controller and the children.
However, if I add a child and then undo the addition, the array controller has the child removed, but it is still there in the children, and all its data has gone. It has not been turned into a fault, and is not marked as deleted.
Seeing as I can't access the data, it makes it impossible for me to do any cleanup because I need to know some data from the node in order to clean up properly. The only thing I can think of to overcome this is to grab the object ID and refetch the object so I can tell what has been deleted. All this just seems as if I must be going about this totally the wrong way, but I don't know any other way of accomplishing it. I did have a look to see if I could work anything out from the managed object context change notification, but couldn't get anywhere there either, and also looked at what was registered with the undo manager, but it didn't seem that the undo manager was being told what the objects were in the undoInsertions etc. I assume it's all managed in the MOC behind the scenes.
So...still stuck, and not sure where to look next.
If your background thread can copy the necessary data, then it doesn't have to worry about it disappearing. My understanding is that accessing a potentially changing MOC from another thread is problematic at best. See Ben Trumbull's posts on this topic. Ex. March 16, 2007
Re: Core Data & threads [re: Ping: Look for hints for "nested transaction" problem with Core Data]
That's a scary discussion - I need to pass in my objects to the processing thread so it can read them - I had no idea there would be a problem with doing that. Yet another thing to learn about Core Data.
So if I understand correctly, instead of just
myObjectInMyThread.node = node;
I would have to do something like:
NSManagedObjectContext *managedObjectContext = [[NSManagedObjectContext alloc] init];
[managedObjectContext setPersistentStoreCoordinator:pscFromMainThread];
myThreadController.managedObjectContext = managedObjectContext;
...
// In my thread (with appropriate will/did change and memory management...), where n is the node from the main MOC
- (void)setNode:(Node *)n {
node = [myThreadController.managedObjectContext objectWithID:[n objectID]];
}
Is that the right sort of approach?
You know, I could have done this project in 1/10th the time or less if I had not used core data - hope it pays off in the long term...
The usual pattern seems to be to have a separate MOC for the background thread and echo changes to it when the MOC in the main thread changes (NSManagedObjectContextObjectsDidChangeNotification).
_______________________________________________
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