core-data - 立即启用文件NSManagedObjectContext的保存？

Question

从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交互，直到第一个自动保存操作完成。

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

有人对我该如何处理有任何想法吗？

Answer 1

所以我无所事事，包括尝试@Aderstedt的建议。这种方法没有用，因为伪造通知似乎只是告诉接收上下文“嘿，检查持久性存储，我已经更新了它们！”，实际上却没有，因为没有。我最终找到了可行的方法。不幸的是，它依赖于仅Lion的功能，因此我仍在寻找一种不需要Lion的方法。

背景

我想使用NSPersistentDocument方法。尽管我在任何地方都没有找到明确记录的文档，但我发现了一些论坛帖子，并获得了大量的经验证据，证明您不能在属于NSPersistentDocument的上下文中调用-[NSManagedObjectContext save:]。正如问题中提到的，如果您在保存文档之前调用它，它将没有任何存储，因此保存将失败。即使在存储存在之后，也可以通过直接保存上下文（而不是通过文档保存API）来有效地更改NSPersistentDocument背后的磁盘上表示形式，并且您会得到如下文件弹出窗口：


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


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

同样值得一提的是：这里的目标是确保UI使用的上下文不会触发（或至少最少）I / O，以保持响应速度。我最终选择的模式是具有3个上下文。 NSPersistentDocument拥有的一个上下文，该上下文将负责与文档一起执行文件I / O。用于绑定UI的第二个有效只读上下文。 （我认识到很多人都希望UI能够改变模型，所以这对他们来说可能不那么令人兴奋，但这对我来说不是必需的。）第三个上下文用于后台线程，该线程从Web异步加载数据服务，并希望将其推送到其他上下文中，以便既可以将其保存在磁盘上也可以在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之前的解决方案实际上是“不要使用NSPersistentDocument”。据我所知，如果我放弃这一要求，所有这些痛点就会消失。否则，您可以随时保存上下文并迁移存储，但是自然地，您必须自己完成所有工作。