On Nov 21, 2010, at 12:50, vincent habchi wrote: > Exactly, that's why I want to change. Note that my needs are fairly basic, so > I didn't see the point of entering into a more complex scheme.
I think the point is that it's far *less* complex because the code to deal with a second MOC should be a lot simpler than the thread locking code. Plus, the chances are that your locking code is wrong. :) (Trust me, that's not a dig at you personally. But multithreading interlocks are *hard*. Such code can work almost all of the time and still be wrong.) > I know I should have two MOCs, but that leads to further difficulties linked > to mutator use. I see fairly clearly how to get a copy of the root entity > (the one that has the NSSet *), but how about the entities at the other end > of the relationship? Should I enumerate all those to get copies, and then > perform the mutation on the copies? Can I directly mutate the set from the > root copy object without making this expensive copying operation? Is the > change immediately reflected in the other MOC (I need real time interaction), > etc. You've added important information. If you're *changing* the objects enumerated in the background thread, you're going to run into difficulties with the NSDocument metaphor. (You can't -[save:] the MOC in the background thread because you shouldn't be changing the document file without the user having a say in it, and you can't release the background MOC without losing the changes. You might be forced to merge the changes back into the original context.) Approach #3 *might* be the best way after all, but I think if you're trying to get multithreaded data changing within a NSDocument/NSPersistentDocument scenario (which is kind of a hack to begin with) you might need to go deeper into the design process anyway. For example, you might be able to break everything (including your current "foreground" and "background" object modification loops) down into smaller steps that you schedule with GCD. Speaking from very painful experience, I'd recommend you be careful trying to design for performance if you need Core Data to behave in certain ways to make the design work. What seems like a small operation from your side of the Core Data API can be something entirely different in the Core Data implementation. (Note that I'm not saying anything against Core Data performance -- it's highly optimized -- but rather against making assumptions about how Core Data implements its behavior. You can't observe Core Data to find out, either. Its implementation characteristics really do change in dramatic ways between Mac OS versions.) _______________________________________________ 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
