NSFetchRequest가 NSManagedObjectContext에서 관계에 대한 변경 사항을 보지 못했습니다.

Question

코어 데이터에 UIManagedDocument를 사용하고 있습니다. calendarSelected 속성이있는 managedObjectContext에 Calendar 객체가 있습니다. Calendar 엔티티는 CalendarEntry와 다 대 관계를 유지합니다. 내가 그들의 calendarSelected 속성을 변경 한 후 다음 술어 CalendarEntry 객체를 얻기 위해 NSFetchRequest을 수행 할 때

:

[NSPredicate predicateWithFormat:@"calendar.calendarSelected = YES"]

는 calendar.calendarSelected 내가 나없이 변경이 호출 볼 수있을 것 같지 않습니다

[myManagedDocument saveToURL:myManagedDocument.fileURL forSaveOperation:UIDocumentSaveForOverwriting completionHandler:^(BOOL success) {}];

첫째. 나는 같은 맥락에서 물건을 가져 오는 것이 변경 사항이 영구 저장소에 쓰여지지 않았더라도 그러한 맥락에서 이루어진 변경을 존중해야한다는 것을 읽었다. 내가 뭘 놓치고 있니?

업데이트 :

그것은 calendarEvents 관계에 오류가있을 때 발생하는 것으로 나타납니다

: calendarEvents = "<relationship fault: 0x91aec90 'calendarEvents'>";하지만 관계가 고장이 아닌 경우 작동합니다.

Answer 1

기본적으로 변경 한 후에는 실행 취소 관리자를 사용하거나 [document updateChangeCount : UIDocumentChangeDone]을 호출해야합니다. 그리고 그게 다야! 다른 "저장"호출은 어딘가에서 줄 바꿈의 다른 것을 끊을 것입니다.

업데이트의 표준 방법이 있어야 할 ...

귀하는 주 스레드에서 알고

NSManagedObjectContext *ctx = document.managedObjectContext; 
// Do stuff with it 
[document updateChangeCount:UIDocumentChangeDone]; 

당신은 다른 스레드에있는

[document.managedObjectContext performBlock:^{ 
    // Do stuff with it on the main thread 
    [document updateChangeCount:UIDocumentChangeDone]; 
}]; 

또는

NSManagedObjectContext *moc = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType]; 
moc.parentContext = document.managedObjectContext; 
[moc performBlock:^{ 
    // Do stuff with it on a background thread 
    // Push changes up to parent (which is the document's main MOC) 
    // The document will know it's dirty and save changes 
    [moc save:&error]; 
}]; 

또는 주 문서 MOC를 엉망으로 만들지 않고 백그라운드 스레드에서 변경하고 싶다면 상위 MOC에서 다음 작업을 수행 할 때까지 기본 MOC를 볼 수 없습니다.

[document.parentContext.managedObjectContext performBlock:^{ 
    // Do stuff with it on a background thread, but the main MOC does not 
    // see the changes until it does a fetch. 
}]; 

Answer 2

문제가 새로 삽입 CalendarEntry 객체가 일대 다 관계가 가리키는에서만 발생하는 경우, 그것은 그들이 아직 고정 된 물체의 ID를하지 않아도 가능합니다. 이것은 객체 ID를 덤프하고 일시적이거나 영구적인지 확인하기 위해 디버그하기 쉽습니다.

다 대다 관계에있는 포함 된 개체가 유지 될 때 이런 현상이 발생했습니다. 그것이 유지되는 한 오랫동안 많은 관계가 포함 된 객체가 영원한 ID를 얻는 지점에 결코 도달하지 않는 것처럼 보입니다. 응용 프로그램을 백그라운드에두고 다시 시작하여 디버깅하기가 쉽습니다. 일반적으로 backgrounding에 의해 UIManagedDocument가 강제적으로 보존됩니다. CalendarEntry 엔티티에는 영구 ID가 할당되어 fetch 가능하게되기 때문에, 나중에 예상대로 일이 시작됩니다.

UIManagedDocument를 저장하는 한 UIManagedDocument를 사용할 때 발생하는 시간을 제어 할 수 없습니다.가장 좋은 방법은 updateChangeCount : UIDocumentChangeDone을 ​​통해 나중에 저장이 수행되도록 예약하는 것입니다.하지만 다시 '곧'발생하지만 결정적으로는 발생하지 않습니다. 즉, 발생 시점을 알 수 없습니다.

일시적인 개체 ID 문제와 영구 개체 ID 문제를 해결하려면 해당 문제가 발생하면 NSManagedObjectContext에서 다음 범주를 시도하십시오. 새로운 CalendarEntry 객체의 삽입이 완료 한 후,이 객체를 강제적으로 호출합니다.

// Obtain permanent ids for any objects that have been inserted into 
// this context. 
// 
// As of this writing (iOS 5.1), we need to manually obtain permanent 
// ids for any inserted objects prior to a save being performed, or any 
// objects that are currently retained, that have relationships to the 
// inserted objects, won't be updated with permanent ids for the related 
// objects when a save is performed unless the retained object is refetched. 
// For many objects, that will never occur, so we need to force the issue. 

- (BOOL)obtainPermanentIDsForInsertedObjects:(NSError **)error 
{ 
    NSSet * inserts = [self insertedObjects]; 

    if ([inserts count] == 0) return YES; 

    return [self obtainPermanentIDsForObjects:[inserts allObjects] 
             error:error]; 
}