On 23 Jan, 2011,at 12:45 PM, Dave Fernandes <[email protected]> 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 protected])
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]
