cocoa - 核心数据对象未正确返回与 10.7 的 NSPrivateQueueConcurrencyType 上下文一致的数据

Question

我有一些现有的 Core Data 代码，它们使用 10.6 及更早版本的模式，在每个新线程中创建一个新的 NSManagedObjectContext，根据需要执行数据修改，保存 NSManagedObjectContext(从而保存到持久存储)，然后任何其他需要更改的上下文可以观察 NSManagedObjectContextDidSaveNotification 并合并更改。

出于各种原因，我正在修改此代码以使用 10.7 的新多线程核心数据功能，方法是更改​​模式，以便我创建的所有上下文都是具有 NSPrivateQueueConcurrencyType 的共享上下文的子级。我保存上下文，然后共享父级观察 NSManagedObjectContextDidSaveNotifications，但我没有像以前那样合并更改，而是简单地保存父级，从而以这种方式传播更改。

我还使用两种持久存储:一种由磁盘上的 SQLite 数据库支持，另一种由内存存储支持。我通过将一个存储中的托管对象的 URI 保存到另一个存储中来存储跨存储关系，如下所示:

- (AFStoredTrack *)storedTrack;
{
    [self willAccessValueForKey:@"storedTrack"];
    AFStoredTrack *theStoredTrack = [self primitiveStoredTrack];
    [self didAccessValueForKey:@"storedTrack"];

    if (theStoredTrack == nil) {
        NSString *IDString = [self storedTrackObjectIDString];
        if (IDString != nil) {
            if (! [IDString isEqualToString:@""]) {
                NSManagedObjectContext *objectContext = [self managedObjectContext];
                NSPersistentStoreCoordinator *coordinator = [objectContext persistentStoreCoordinator];
                NSURL *objectURL = [NSURL URLWithString:IDString];
                NSManagedObjectID *storedTrackObjectID = [coordinator managedObjectIDForURIRepresentation:objectURL];

                NSError *retrieveError = nil;
                theStoredTrack = (AFStoredTrack *)[objectContext existingObjectWithID:storedTrackObjectID error:&retrieveError];

                if (theStoredTrack) {
                    [self setPrimitiveStoredTrack:theStoredTrack];
                }
            }
        }
    }

    return theStoredTrack;
}

- (void)setStoredTrack:(AFStoredTrack *)aStoredTrack;
{
    [self willChangeValueForKey:@"storedTrack"];

    NSString *stringRepresentation = nil;
    if (aStoredTrack) {
        NSManagedObjectID *theObjectID = [aStoredTrack objectID];
        if ([theObjectID isTemporaryID]) {
            [NSException raise:@"AFTriedToSetTemporaryStoredTrack"
                        format:@"You tried to set a temporary AFStoredTrack!"];
        }
        stringRepresentation = [[theObjectID URIRepresentation] absoluteString];
    }

    [self setPrimitiveStoredTrack:aStoredTrack];
    [self setValue:stringRepresentation
            forKey:@"storedTrackObjectIDString"];

    [self didChangeValueForKey:@"storedTrack"];
}

AFStoredTracks 由磁盘存储支持。 self 是一个由内存存储支持的 NSManagedObject。

此代码与 10.6 及更早版本的模式完美配合。然而，它在修改后的代码中失败了。由于某种原因， -storedTrack 方法返回的 AFStoredTrack 对象有时只是空壳(任何检索到的属性都为零)，有时它们会抛出一个异常，指出 Core Data 无法完成错误。

奇怪的是，如果我将此代码添加到 -storedTrack 方法中:

- (AFStoredTrack *)storedTrack;
{
    ...

    if (theStoredTrack == nil) {
        ...
    } else {
        if ([theStoredTrack isFault]) {
            NSManagedObjectContext *objectContext = [self managedObjectContext];
            NSPersistentStoreCoordinator *coordinator = [objectContext persistentStoreCoordinator];
            NSURL *objectURL = [NSURL URLWithString:IDString];
            NSManagedObjectID *storedTrackObjectID = [coordinator managedObjectIDForURIRepresentation:objectURL];

            NSError *retrieveError = nil;
            AFStoredTrack *testTrack = (AFStoredTrack *)[objectContext existingObjectWithID:storedTrackObjectID error:&retrieveError];
            NSLog(@"AFStoredTrack: %@",testTrack);
        }
    }
    ...
}

然后，AFStoredTracks 会使用正确的数据进行记录，而不是 null 或引发异常。如果您注意到，这与上一个 block 中用于首先设置原始storedTrack 属性的代码完全相同。好像没有什么意义。

我已检查以确保 AFStoredTrack 和从中访问它的 NSManagedObject 也使用相同的上下文。 磁盘上的数据都在 SQLite 文件中，就像如果扑救按预期进行的话就应该是这样。我什至记录了 AFStoredTrack 对象的存储 URI，并且它们是有效的 - 第一个 block 和第二个 block 中的 URI 显示相同的托管对象 URI，即使第一个 block 获取伪造的 nil 数据或引发异常，第二个得到正确的数据。

[更新:呃，我收回那句话，NSManagedObject 及其 AFStoredTrack 原始属性不具有相同的 NSManagedObjectContext:

- (AFStoredTrack *)storedTrack;
{
    ...

    if (theStoredTrack == nil) {
        ...
    } else {
        NSManagedObjectContext *storedTrackContext = [theStoredTrack managedObjectContext];
        NSManagedObjectContext *selfContext = [self managedObjectContext];
        if (storedTrackContext != selfContext) {
            NSLog(@"self context: %@, storedTrack context: %@",selfContext,storedTrackContext);
        }
        ...
    }
    ...
}

我从这个代码片段中获取日志行，此外，storedTrackContext 有时(但并非总是)将自身记录为“(null)”!哈？!？ NSManagedObject 怎么可能没有上下文呢？这更没有意义。

也许有些东西发生了变化，并且不可能(或更难)拥有具有 NSManagedObject 原始值的属性？]

有人知道发生了什么吗？

Answer 1

I save the contexts, and then the shared parent observes the NSManagedObjectContextDidSaveNotifications, but instead of merging the changes as before, I simply save the parent, thereby propagating the changes that way.

实际上恰恰相反。保存时，更改会自动从子上下文传播到父上下文。子上下文不会自动接收父上下文中的更改。如果您需要子上下文的最新数据，则需要刷新对象。

这就是 UIManagedDocument 在内部使用父上下文并为开发人员公开子上下文的原因。

最诚挚的问候，

斯文。