Re-reading the documentation for concurrent managed object contexts in
preparation for moving some of my slower DB work off the main thread.
It's very clear that messages you send to the MOC must be inside performBlock:
or performBlockAndWait:, so if I execute a fetch request or anything else with
that MOC, a line of the form
[ concurrentMOC doSomethingWith:something ]
that must be inside a performBlock[AndWait]: call. This makes total sense.
executeQuery is one of those calls which I do quite a bit. The documentation
talks about "standard messages to send to the context".
How about the objects which are then owned by the MOC, the managed objects? Do
any messages sent to them, even a property or relationship lookup, need also to
be in a performBlock: call on the MOC owning those objects? I thought about it
and eventually decided, perhaps, if the data isn't there and they are faults,
the MOC is going to have to do something to fill them and that something should
surely be done on its thread. But I can't find that stated anywhere and if it's
the case it massively complicates the code. Just getting one property from one
managed object (which was handed to you and may be from a non-main-thread MOC)
means accessing a property becomes
id __block theProperty = nil;
[ foo.managedObjectContext performBlockAndWait:^{
theProperty = foo.property;
} ];
instead of just using foo.property directly.
Or are MOC's smart enough to figure this out and fulfil their internal faults
with the equivalent to performBlockAndWait: and only messages sent directly to
the MOC need to be done inside a block?
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
