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 초 지연은 효과가 있다는 것을 알았습니다.
하지만이 지연에 의존하고 싶지 않습니다. 이것은 많은 데이터가없는 테스트 환경이며 프로덕션 환경에서 어떤 일이 발생할지 모르겠습니다. 실험적 지연에 의존하는 것은 올바른 일이 아닌 것 같습니다.
옳은 것이 있습니까? 아니면 처음부터 뭔가 잘못하고 있습니까?
답변
경험상 알림 이외의 다른 알림을 듣는 것은 NSManagedObjectContextDidSaveNotification엉망이며 아직 업데이트되지 않은 속성에 의존 할 수 있습니다. 자세히보기 컨트롤러는 NSManagedObjectContextDidSaveNotification캐스케이드가 적용된 후 발생하는 알림을 수신해야합니다 . 그런 다음 현재 개체가 유효한지 여부를 여러 가지 방법으로 확인할 수 있습니다 (현재 개체의 관리 개체 컨텍스트가 유효한지 확인 nil하거나 가져 오기를 수행하고 개체가 저장소에 있는지 확인할 수 있음).
