【问题标题】:Enable saving of document NSManagedObjectContext immediately?立即启用文档 NSManagedObjectContext 的保存?
【发布时间】:2012-02-01 23:11:33
【问题描述】:

从 10.7 上带有 CoreData 模板的标准 Xcode 基于文档的应用程序开始,我遇到了一些令人沮丧的行为。我确定我忽略了一些简单的事情。

假设在我的 NSPersistentDocument 子类中,我有这样的东西,连接到窗口中的一个按钮:

- (IBAction)doStuff:(id)sender
{        
    NSEntityDescription* ent = [[self.managedObjectModel entitiesByName] valueForKey: @"MyEntity"];
    NSManagedObject* foo = [[[NSManagedObject alloc] initWithEntity: ent insertIntoManagedObjectContext: self.managedObjectContext] autorelease];
    [self.managedObjectContext save: NULL];
}

如果我创建一个新文档并单击该按钮,我将收到以下错误:This NSPersistentStoreCoordinator has no persistent stores. It cannot perform a save operation. 我明白了。我们还没有保存,没有持久存储。说得通。

现在假设我把它分成两个动作,连接到不同的按钮,如下所示:

- (IBAction)doStuff:(id)sender
{        
    NSEntityDescription* ent = [[self.managedObjectModel entitiesByName] valueForKey: @"MyEntity"];
    NSManagedObject* foo = [[[NSManagedObject alloc] initWithEntity: ent insertIntoManagedObjectContext: self.managedObjectContext] autorelease];
}

- (IBAction)doOtherStuff:(id)sender
{        
    [self.managedObjectContext save: NULL];
}

如果我创建一个新文档并按下第一个按钮,然后在按下该按钮(弄脏文档)后的某个不确定时间,自动保存将出现并自动保存文档,这将在临时位置创建一个存储。如果我再按第二个按钮,就没有投诉(因为现在有一家商店。)

我需要我的文档能够从一开始就进行 managedObjectContext 保存。我在后台线程上开始了一些事情,我需要后台上下文的保存操作(和通知),以便将后台线程所做的更改合并到主线程的 managedObjectContext 中。

我曾想过尝试强制自动保存,但自动保存过程似乎完全异步,所以我不得不跳过任何可能导致 managedObjectContext 保存的 UI 交互,直到第一次自动保存操作完成。

我也考虑过创建一个内存存储来弥补创建新文档和第一次自动保存之间的差距,但是我不清楚如何将内存存储迁移到磁盘存储并删除内存存储与第一次自动保存操作同步。

有人对我如何处理这个问题有任何想法吗?

【问题讨论】:

  • 您是否在初始化时创建了商店?
  • 不,我没有,因为我特别希望临时存储(在用户启动的文档保存之前)位于自动保存机制认为的任何位置。

标签: core-data core-data-migration


【解决方案1】:

所以我玩弄了一段时间,包括尝试@Aderstedt 的建议。这种方法不起作用,因为伪造通知似乎只是告诉接收上下文“嘿,检查持久存储,我已经更新了它们!”,而实际上,我没有,因为没有。我最终找到了一种有效的方法。不幸的是,它依赖于仅 Lion 的功能,所以我仍在寻找一种不需要 Lion 的方法。

背景

我想使用 NSPersistentDocument 方法。尽管我没有在任何地方找到明确记录,但我发现了几个论坛帖子,并经历了一堆经验证据,证明您不能在属于 NSPersistentDocument 的上下文中调用-[NSManagedObjectContext save:]。如问题中所述,如果您在保存文档之前调用它,它将有 no 存储,因此保存将失败。即使在存储存在之后,通过直接保存上下文(而不是通过文档保存 API),您也可以有效地更改 NSPersistentDocument 背后的磁盘表示形式,并且您将获得显示以下内容的文档弹出表:

文件已被另一个应用程序修改

简而言之,NSPersistentDocument 期望控制关联的 NSManagedObjectContext 本身的保存操作。

另外值得一提的是:这里的目标是确保 UI 使用的上下文不会触发(或至少是最少的)I/O,以保持响应。我最终确定的模式是有 3 个上下文。 NSPersistentDocument 拥有的一个上下文,它将负责与文档一起执行文件 I/O。用于将 UI 绑定到的第二个有效只读上下文。 (我意识到很多人想要改变模型的 UI,所以这对他们来说可能不那么令人兴奋,但这对我来说不是必需的。)第三个上下文用于从网络异步加载数据的后台线程服务,并希望将其推送到其他上下文中,以便它既可以保存在磁盘上又可以在 UI 中呈现,而不会潜在地阻塞网络 I/O 上的 UI。

狮子专用解决方案

Lion 的 CoreData 实现中的新父/子 NSManagedObjectContext 功能完美。我用并发类型 NSPrivateQueueConcurrencyType 的新 MOC 替换了 NSPersistentDocument 的 NSManagedObjectContext。这将是“根”上下文。然后,我使用 NSMainQueueConcurrencyType 并发创建了 UI 上下文,并使其成为根上下文的子级。最后,我将网络加载上下文设为 NSPrivateQueueConcurrencyType 上下文,它是 UI 上下文的子上下文。它的工作方式是我们在后台启动网络加载操作,它会更新网络上下文。完成后,它会保存上下文。对于父/子关系,保存子上下文会将更改推送到父上下文(UI 上下文),但将父上下文保存到存储中。就我而言,我还从网络上下文中监听 NSManagedObjectContextDidSaveNotification 通知,然后告诉它的父级也保存(这会将更改从 UI 上下文推送到根/磁盘上下文中,但不会将其保存到磁盘。)

在这一系列事件的最后,所有上下文都是一致的,我们仍然没有强制真正保存底层根上下文,因此我们没有与 NSPersistentDocument 的管理角色发生冲突磁盘上的表示。

一个问题是,如果您想防止子上下文的保存生成撤消(即这是一个网络加载操作,没有什么可撤消的),您必须在将更改沿链传播时在每个父上下文上禁用UndoRegistration。

狮子前的努力

我真的很想为这个问题找到一个与 Lion 兼容的解决方案。在放弃之前我尝试了一些东西。我首先尝试在文档初始化时将内存存储与 PSC 关联,这样我就可以在保存文档之前进行 NSManagedObjectContext 保存,然后在第一次保存时迁移内存存储。那部分效果很好。但是一旦存在磁盘存储,这种方法就是虚假的,因为在将其保存到磁盘后,我们会遇到同样的问题,即连接到 NSPersistentDocument 拥有的 PSC 的任何 MOC 的保存都必须由文档完成。

我还尝试破解一种机制,使用 NSManagedObjectContextObjectsDidChangeNotification 有效负载将更改从一个上下文移动到另一个上下文。尽管我能够让它发挥作用(对于“工作”的一些名义定义),但我看到这种方法即将出现大问题。具体来说,迁移这些更改一次很容易,但如果在保存操作之前再次更改呢?然后,我将被困在维护源上下文中的 OID 到目标上下文中的 OID 的长期映射中。这变得非常丑陋。如果有人感兴趣,这就是我想出的:

@interface NSManagedObjectContext (MergeChangesFromObjectsDidChangeNotification)
- (void)mergeChangesFromObjectsDidChangeNotification: (NSNotification*)notification;
@end

@implementation NSManagedObjectContext (MergeChangesFromObjectsDidChangeNotification)

- (void)mergeChangesFromObjectsDidChangeNotification: (NSNotification*)notification
{
    if (![NSManagedObjectContextObjectsDidChangeNotification isEqual: notification.name])
        return;

    if (notification.object == self)
        return;

    NSManagedObjectContext* sourceContext = (NSManagedObjectContext*)notification.object;

    NSAssert(self.persistentStoreCoordinator == sourceContext.persistentStoreCoordinator, @"Can't merge changes between MOCs with different persistent store coordinators.");

    [sourceContext lock];

    // Create object in the local context to correspond to inserted objects...
    NSMutableDictionary* foreignOIDsToLocalOIDs = [NSMutableDictionary dictionary];
    for (NSManagedObject* foreignMO in [[notification userInfo] objectForKey: NSInsertedObjectsKey])
    {
        NSManagedObjectID* foreignOID = foreignMO.objectID;
        NSManagedObject* localMO = [[[NSManagedObject alloc] initWithEntity: foreignMO.entity insertIntoManagedObjectContext: self] autorelease];
        [foreignOIDsToLocalOIDs setObject: localMO.objectID forKey: foreignOID];
    }

    // Bring over all the attributes and relationships...
    NSMutableSet* insertedOrUpdated = [NSMutableSet set];
    [insertedOrUpdated unionSet: [[notification userInfo] objectForKey: NSInsertedObjectsKey]];
    [insertedOrUpdated unionSet: [[notification userInfo] objectForKey: NSUpdatedObjectsKey]];

    for (NSManagedObject* foreignMO in insertedOrUpdated)
    {
        NSManagedObjectID* foreignOID = foreignMO.objectID;
        NSManagedObjectID* localOID = [foreignOIDsToLocalOIDs objectForKey: foreignOID];
        localOID = localOID ? localOID : foreignOID;
        NSManagedObject* localMO = [self objectWithID: localOID];

        // Do the attributes.
        [localMO setValuesForKeysWithDictionary: [foreignMO dictionaryWithValuesForKeys: [[foreignMO.entity attributesByName] allKeys]]];

        // Do the relationships.
        NSDictionary* rByName = foreignMO.entity.relationshipsByName;
        for (NSString* key in [rByName allKeys])
        {
            NSRelationshipDescription* desc = [rByName objectForKey: key];
            if (!desc.isToMany)
            {
                NSManagedObject* relatedForeignMO = [foreignMO valueForKey: key];
                NSManagedObjectID* relatedForeignOID = relatedForeignMO.objectID;
                NSManagedObjectID* relatedLocalOID = [foreignOIDsToLocalOIDs objectForKey: relatedForeignOID];
                relatedLocalOID = relatedLocalOID ? relatedLocalOID : relatedForeignOID;
                NSManagedObject* localRelatedMO = [self objectWithID: relatedLocalOID];
                [localMO setValue: localRelatedMO forKey: key];
            }
            else
            {
                id collection = [foreignMO valueForKey: key];
                id newCollection = [NSMutableSet set];
                if ([collection isKindOfClass: [NSOrderedSet class]])
                {
                    newCollection = [NSOrderedSet orderedSet];
                }

                for (NSManagedObject* relatedForeignMO in collection)
                {
                    NSManagedObjectID* relatedForeignOID = relatedForeignMO.objectID;
                    NSManagedObjectID* relatedLocalOID = [foreignOIDsToLocalOIDs objectForKey: relatedForeignOID];
                    relatedLocalOID = relatedLocalOID ? relatedLocalOID : relatedForeignOID;
                    NSManagedObject* localRelatedMO = [self objectWithID: relatedLocalOID];
                    [newCollection addObject: localRelatedMO];
                }
                [localMO setValue: newCollection forKey: key];
            }
        }
    }

    // And delete any objects which pre-existed in my context.
    for (NSManagedObject* foreignMO in [[notification userInfo] objectForKey: NSDeletedObjectsKey])
    {
        NSManagedObjectID* foreignOID = foreignMO.objectID;
        NSManagedObject* localMO = [self existingObjectWithID: foreignOID error: NULL];
        if (localMO)
        {
            [self deleteObject: localMO];
        }
    }

    [sourceContext unlock];
}

@end

结论

在并发管理的改进和这个父/子功能之间,我很快就失去了追求前 Lion 解决方案的兴趣。我开始收集到,Lion 之前的解决方案实际上是“不要使用 NSPersistentDocument”。据我所知,如果我放弃该要求,所有这些痛点都会消失。没有它,您可以随时保存上下文并迁移商店,但您自然必须自己完成所有工作。

【讨论】:

  • 很高兴看到其他人也遇到了以下问题:“即使在商店存在之后,通过直接保存上下文(而不是通过文档保存 API),您也会得到文档弹出表说(有效地),“其他人更改了磁盘上的文件;还原或覆盖?”。这会有所帮助。你可以看到我的问题stackoverflow.com/questions/21706343/…
【解决方案2】:

这里的问题是,由 NSPersistentDocument 创建的默认 NSManagedObjectContext 是并发类型 NSConfinementConcurrencyType。 CoreData 不允许创建具有该类型的上下文的子上下文。

作为一种解决方法,这对我有用。 NSManagedObjectContext 由您的 NSPersistentDocument 创建,因此您可以覆盖该方法:

- (NSManagedObjectContext *)managedObjectContext {
    if (!_context) {
        NSManagedObjectContext *_default = [super managedObjectContext];
        _context = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
        _context.persistentStoreCoordinator = _default.persistentStoreCoordinator;
    }

    return _context;
}

我不知道从哪里获取persistentStoreCoordinator,所以我调用了超级实现并从那里获取它。有了这个上下文,您应该能够从中创建可以在后台操作中使用的子上下文。

【讨论】:

    【解决方案3】:

    如果您没有商店,则无法保存。您似乎想保存文档以合并在后台线程上所做的更改;好吧,您可以手动合并这些更改。当后台线程完成后,告诉主线程哪些对象已被更新/插入,然后在主线程上进行相同的更改。

    如果更改几乎是任意的,因此复制起来很繁琐,您甚至可以在后台线程上构建自己的 NSManagedObjectContextDidSaveNotification,然后在主线程上使用 -[NSManagedObjectContext mergeChangesFromContextDidSaveNotification:] 将其合并。

    【讨论】:

    • 让我确定我理解:您是在建议我实际上不保存背景上下文,而是构造一个包含更改的虚假通知?后续保存会发生什么?还是我只是在将它们编组到主线程的上下文后回滚后台上下文的更改?
    • 一旦后台线程完成并合并更改,您可以简单地丢弃后台托管对象上下文。保存主线程托管对象上下文时,对象将被保存。
    • 您对如何生成假的 NSManagedObjectContextDidSaveNotification 有任何指示吗?
    • 用 -[NSManagedObjectContext insertedObjects]、-[NSManagedObjectContext updatedObjects] 和 -[NSManagedObjectContext deletedObjects] 的输出存储 userInfo 字典
    • 这真的行不通。原因如下:当您发送虚假通知时,它的意思是“我已经更改了底层存储,您应该更新这些对象的状态。”但这些对象不在底层存储中,因为没有。我想通了,并将在另一个答案中发布完整的详细信息。
    【解决方案4】:

    我找到了一个写得很好的解决方案,类似于 ipmcc 的解决方案(也在后台线程中运行 NSPersistentDocument 的 MOC,并使其成为主线程 MOC 的父上下文)here.

    它包含基于该文档应用程序的完整 BSD 许可代码(基本上是 iOS 的 UIManagedDocument 的 Mac OS 版本)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2023-03-26
      • 2013-11-13
      • 1970-01-01
      • 2015-09-02
      • 1970-01-01
      • 2012-02-20
      • 1970-01-01
      相关资源
      最近更新 更多