ios - 一对一的关系如何在willTurnIntoFault中退化为NSManagedObjectID？

这是代码:

- (void)willTurnIntoFault {
    NSManagedObject *relatedObject = self.relatedObject;
    if (relatedObject != nil && !relatedObject.isFault && !relatedObject.hasChanges) {
        [relatedObject.managedObjectContext refreshObject:relatedObject mergeChanges:NO];
    }

    [super willTurnIntoFault];
}

这是崩溃:

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[_NSObjectID_64_1 hasChanges]: unrecognized selector sent to instance 0x158601a0'

Last Exception Backtrace:
0   CoreFoundation                      0x307bfe8b __exceptionPreprocess + 131
1   libobjc.A.dylib                     0x3aab96c7 _objc_exception_throw + 39
2   CoreFoundation                      0x307c37b7 -[NSObject(NSObject) doesNotRecognizeSelector:] + 203
3   CoreFoundation                      0x307c20b7 ___forwarding___ + 707
4   CoreFoundation                      0x30710e98 __CF_forwarding_prep_0 + 24
5   Moke                                0x0017cd51 -[Status willTurnIntoFault] (Status.m:420)
6   CoreData                            0x305356eb -[NSFaultHandler turnObject:intoFaultWithContext:] + 67
7   CoreData                            0x305333bb -[NSManagedObject dealloc] + 75
8   CoreData                            0x30532b85 -[_PFManagedObjectReferenceQueue _processReferenceQueue:] + 1557
9   CoreData                            0x305393c7 -[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] + 3795
10  CoreData                            0x30532505 _performRunLoopAction + 317
11  CoreFoundation                      0x3078af71 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 21
12  CoreFoundation                      0x307888ff __CFRunLoopDoObservers + 287
13  CoreFoundation                      0x30788c4b __CFRunLoopRun + 739
14  CoreFoundation                      0x306f3541 _CFRunLoopRunSpecific + 525
15  CoreFoundation                      0x306f3323 _CFRunLoopRunInMode + 107
16  GraphicsServices                    0x3542a2eb _GSEventRunModal + 139
17  UIKit                               0x32faa1e5 _UIApplicationMain + 1137
18  Moke                                0x000f47e7 main (main.m:16)
19  libdyld.dylib                       0x3afb2ab7 start + 3

这是self对象:

<Status: 0x16a705c0> (entity: Status; id: 0x16a31700 <x-coredata://66EAF889-7CD5-48C2-999E-5E15B84BF8FA/Status/p2235> ; data: {
    ID = 3622738251833351;
    relatedObject = "0x16a40340 <x-coredata://66EAF889-7CD5-48C2-999E-5E15B84BF8FA/Status/p2242>";
    text = "...";
    user = "0x16824200 <x-coredata://66EAF889-7CD5-48C2-999E-5E15B84BF8FA/User/p948>";
})

因此，在这种条件下!relatedObject.hasChanges看来relatedObject变为_NSObjectID_64_1(这是NSManagedObjectID的子类)。但是怎么可能呢？

PS:如果您好奇为什么它不会在!relatedObject.isFault上崩溃，那是因为_NSObjectID_64_1在我的测试中确实实现了ifFault。

最佳答案

似乎您正在线程之间转移托管对象。尝试通过以下方式增强代码:

//NSManagedObject *relatedObject = self.relatedObject;
NSManagedObject *relatedObject = [self.managedObjectContext existingObjectWithID:self.relatedObject.objectID error:nil];

关于ios - 一对一的关系如何在willTurnIntoFault中退化为NSManagedObjectID？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/18835575/