ios - "1 moc per thread"策略和 "child moc"策略混合使用是否有效？

Question

直到现在，我一直对主线程使用“main moc”，初始化如下:

[[NSManagedObjectContext alloc] init];

然后我有 NSOperation 子类，它们有自己的 moc 从 web 服务导入数据，我在保存时合并到“主”moc 观察 NSManagedObjectContextDidSaveNotification但是现在我需要能够添加用户以后可以提交(或不提交)的“临时”对象。所以看起来子上下文是最合适的，为了使用子上下文，我将“主 moc”的初始化更改为

 [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];

问题是:如果与子上下文策略一起使用，我当前的结构是否有 NSOperation 子类和它们自己的 moc(在它们自己的线程中没有类型初始化)有问题吗？我不这么认为，但我没有发现太多关于混合这些策略的信息。

请注意，我想维护 NSOperation 子类并且我不想也使用子上下文来导入我的数据，因为它会影响性能，请参阅 http://floriankugler.com/blog/2013/4/29/concurrent-core-data-stack-performance-shootout

此外，当我创建主线程的新子线程(类型为NSMainQueueConcurrencyType)时，我能否创建该子线程并继续工作像往常一样在主线程中使用我的对象？或者我是否被迫使用 NSPrivateQueueConcurrencyType，并为我的对象的每个操作使用 performBlock:？我问是因为在同一个线程(在本例中是主线程)上使用 2 个 moc 可能是个问题，文档中并不清楚。

更新:最后我在生产中实现并使用了这个解决方案，到目前为止没有问题。我唯一需要做的就是避免在 moc 具有 parentContext 时合并我的 NSManagedObjectContextDidSaveNotification 通知(我们不想将 mocs 与父上下文合并，因为他们自己管理合并，但显然在这种 moc 上也会为 save 触发通知)

Answer 1

是的，您可以有多个主队列上下文 moc，这正是您所说的原因 - 您创建一个临时编辑上下文来编辑数据，然后根据用户操作保存或丢弃这些数据。

至于与您的操作队列上下文混合和匹配 - 这应该不是问题。如果您要合并回父上下文，那么任何子上下文都将在下次获取时获取该数据。