CoreData
항목 "A"는 CoreData
계단식 삭제 규칙을 사용하여 항목 "B" 모음과 일대 다 관계를 갖습니다 .
에서 iCloud
환경 동안 1 개 표시 장치 "B"항목 중 하나, 장치 (2 개) 삭제하고 "A"항목의 상세도.
NSPersistentStoreDidImportUbiquitousContentChangesNotification
알림이 장치 1에서 수신 되면 App Delegate가 호출 mergeChangesFromContextDidSaveNotification
한 다음 항목 "B"의 세부 정보를 표시하는 뷰 컨트롤러가 캡처 한 내부 알림을 브로드 캐스트합니다 (코드는 필요한 performBlock
위치를 사용 합니다).
그러나 상세보기 컨트롤러가 내부 알림을 수신하면 항목 "A"가 실제로 무효화 되더라도 항목 "B"는 여전히 유효한 CoreData
객체 로 존재 합니다. 캐스케이드 규칙이 아직 작동을 완료하지 않은 것 같습니다. 따라서 장치 1의 뷰 컨트롤러는 삭제를 인식하지 못하므로 예기치 않은 결과가 발생할 수 있습니다.
mergeChangesFromContextDidSaveNotification
기본 데이터가 병합되었지만 Cascade 규칙이 아직 완료되지 않은 경우 조기에 반환되는 것처럼 보입니다.
stalenessInterval
캐시 된 개체가 사용되지 않도록 관리 개체 컨텍스트를 일시적 으로 0 으로 설정하는 동안 알림이 도착하면 항목 "B"를 새로 고치려고 했지만 저장소에서 유효한 항목 "B"를 가져옵니다.
null
이 시점에서 항목 "A"를 확인 하는 것은 옵션이 아닙니다. 상황이 여기에서 설명한 것보다 다소 복잡하고 경우에 따라 null 항목 "A"가 유효 할 수 있기 때문입니다.
변경 사항을 병합 한 후 내부 알림을 뷰 컨트롤러에 보내기 전에 지연을 도입하려고했습니다. 2 초 지연은 도움이되지 않지만 10 초 지연은 효과가 있다는 것을 알았습니다.
하지만이 지연에 의존하고 싶지 않습니다. 이것은 많은 데이터가없는 테스트 환경이며 프로덕션 환경에서 어떤 일이 발생할지 모르겠습니다. 실험적 지연에 의존하는 것은 올바른 일이 아닌 것 같습니다.
옳은 것이 있습니까? 아니면 처음부터 뭔가 잘못하고 있습니까?