CoreData + iCloud + Cascade Delete - 처리 방법은 무엇입니까?

Question

CoreData 엔티티 "A"는 캐스케이드 삭제 규칙을 사용하여 CoreData 항목 "B"의 모음과 일대 다 관계를 유지합니다.

iCloud 환경에서 장치 1은 "B"항목 중 하나의 세부보기를 표시하지만 장치 2는 "A"항목을 삭제합니다. NSPersistentStoreDidImportUbiquitousContentChangesNotification 통지 장치 (1)에서 수신된다

, 그 응용 대리인이 mergeChangesFromContextDidSaveNotification를 호출하고 다음 엔트리 "B"의 세부 사항을 나타내는 도면 제어기에 의해 포착되는 내부 통지를 방송한다 (코드 performBlock 어디서 그것을한다 사용함).

그러나 세부보기 컨트롤러가 내부 알림을 수신 할 때 항목 "A"가 실제로 무효화 되더라도 항목 "B"는 유효한 CoreData 개체로 계속 존재합니다. 캐스케이드 규칙은 아직 작업을 완료하지 않은 것 같습니다. 따라서 장치 1의보기 컨트롤러는 삭제를 인식하지 않으므로 예기치 않은 결과가 발생할 수 있습니다.

mergeChangesFromContextDidSaveNotification은 기본 데이터가 병합되었지만 계단식 규칙이 아직 완료되지 않은 경우 조기에 반환 된 것처럼 보입니다.

관리 대상 객체 컨텍스트의 stalenessInterval을 일시적으로 0으로 설정하면서 알림이 도착하면 항목 B를 새로 고쳐 내려고 했으므로 캐시 된 객체는 사용되지 않지만 여전히 유효한 항목 "B"가 표시됩니다. 저장.

null 항목 확인 여기에 설명 된 것보다 상황이 다소 복잡하고 경우에 따라 null 항목 "A"가 유효 할 수 있기 때문에이 시점에서 "A"는 옵션이 아닙니다.

변경 사항을 병합하고 내부 알림을보기 컨트롤러에 보내기 전에 지연을 도입하려고했습니다. 나는 2 초의 지연이 도움이되지 않는다는 것을 알았지 만 10 초의 지연이 작용한다.

하지만이 지연에 의존하고 싶지는 않습니다. 이것은 많은 데이터가없는 테스트 환경이며 프로덕션 환경에서 어떤 일이 발생할지 모릅니다. 실험적인 지연에 의존하는 것은 올바른 일이 아닌 것처럼 보입니다.

옳은게 있나요? 아니면 처음부터 잘못된 것을하고 있습니까?

Answer 1

경험상, NSManagedObjectContextDidSaveNotification 이외의 알림을 듣는 것은 큰 혼란이며 아직 업데이트되지 않은 속성에 의존 할 수 있습니다. 상세보기 컨트롤러는 계단식 적용 후 던져지는 NSManagedObjectContextDidSaveNotification 알림을 수신해야합니다. 그런 다음 현재 개체가 유효한지 여러 가지 방법으로 확인할 수 있습니다 (현재 개체의 관리되는 개체 컨텍스트가 nil인지 확인하거나 패치를 수행하고 개체가 저장소에 있는지 확인할 수 있음).