On 2011-01-23, at 3:56 AM, Kenneth Baxter wrote:
> On 23 Jan, 2011,at 12:45 PM, Dave Fernandes <dave.fernan...@utoronto.ca>
> 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.
This certainly doesn't sound right. The only thing I can think of is to make
sure you call [managedObjectContext processPendingChanges] after completing all
your changes to the data model (each event cycle).
>
> 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?
Aside from the fact that you are still accessing a node from the main thread's
MOC from within the background thread, I think there might be a problem even
with access by object ID. If you have newly created a child and have not saved
the changes, then the object ID is "temporary" and I don't think you will be
able to retrieve a valid object from the BG thread's MOC. So I presume you will
have to recreate the object in the BG thread by, say, passing in a dictionary
containing the node's data.
We are getting more and more into territory that I have no experience with. So
I will refrain from any more conjecture in public.
>
> 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...
Yes, I still say that sometimes, but I'm still using it.
Cheers,
Dave
>
>>
>>
>> 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 (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 arch...@mail-archive.com
