2012-05-11 30 views
78

CoreData Pháp nhân "A" có mối quan hệ một-nhiều với một bộ sưu tập của CoreData Mục nhập "B", sử dụng quy tắc xóa Cascade.CoreData + iCloud + Cascade Delete - cách xử lý?

Trong môi trường iCloud, trong khi thiết bị 1 hiển thị chế độ xem chi tiết của một trong các mục nhập "B", thiết bị 2 sẽ xóa mục nhập "A".

Khi nhận được thông báo NSPersistentStoreDidImportUbiquitousContentChangesNotification trong thiết bị 1, App Delegate gọi mergeChangesFromContextDidSaveNotification và sau đó phát thông báo nội bộ được bộ điều khiển chế độ xem hiển thị chi tiết mục nhập "B" (mã sử dụng performBlock nơi cần).

Tuy nhiên, mặc dù mục "A" thực sự bị vô hiệu hóa khi trình điều khiển xem chi tiết nhận được thông báo nội bộ, mục "B" vẫn tồn tại dưới dạng đối tượng CoreData hợp lệ. Dường như quy tắc Cascade vẫn chưa hoàn thành hoạt động của nó. Do đó, bộ điều khiển xem trong thiết bị 1 không nhận biết được việc xóa, điều này có thể dẫn đến kết quả không mong muốn.

mergeChangesFromContextDidSaveNotification dường như quay lại sớm, khi dữ liệu cơ sở đã được hợp nhất nhưng quy tắc Cascade chưa hoàn thành.

Tôi cố gắng làm mới mục "B" khi thông báo đến khi tạm thời đặt stalenessInterval ngữ cảnh đối tượng được quản lý về 0 để đối tượng được lưu vào bộ nhớ cache sẽ không được sử dụng, nhưng tôi vẫn nhận được mục nhập hợp lệ "B" cửa hàng.

Kiểm tra mục nhập "A" tại thời điểm này không phải là một tùy chọn, vì tình huống hơi phức tạp hơn những gì tôi đã mô tả ở đây và mục nhập "A" có thể hợp lệ trong một số trường hợp.

Tôi đã cố gắng giới thiệu độ trễ sau khi hợp nhất các thay đổi và trước khi gửi thông báo nội bộ tới bộ điều khiển chế độ xem. Tôi phát hiện ra rằng sự chậm trễ 2 giây không có tác dụng, nhưng thời gian trễ là 10 giây.

Nhưng tôi không muốn dựa vào sự chậm trễ này. Đây là môi trường thử nghiệm không có nhiều dữ liệu và tôi không biết điều gì sẽ xảy ra trong môi trường sản xuất. Dựa vào một sự chậm trễ thử nghiệm dường như không phải là điều đúng đắn để làm.

Có điều gì không? Hay tôi đang làm gì đó sai để bắt đầu?

+0

Có nhiều điều hơn là có vẻ vì các lần xóa tầng được truyền đi ngay khi nó đến trước: processPendingChanges, lưu hoặc kết thúc chu kỳ vòng lặp chạy. Trong điều kiện bình thường, vấn đề bạn mô tả không nên tồn tại. – svena

+0

là ID đối tượng được quản lý cho đối tượng trong trình điều khiển chế độ xem chi tiết trong mảng NSDeletedObjectsKey đi kèm với NSPersistentStoreDidImportUbiquitousContentChangesNotification? – ImHuntingWabbits

+0

Điều này có luôn xảy ra hay không liên tục? Tôi có một cấu trúc phân cấp phức tạp và chưa thấy bất kỳ đứa trẻ mồ côi nào! Bạn đang tìm nạp thực thể B một lần nữa, hoặc nó có thể là bởi vì bạn đang hiển thị nó bằng cách nào đó bạn đang giữ lại một tham chiếu đến đối tượng. Điều gì sẽ xảy ra nếu bạn đóng ứng dụng và mở lại ứng dụng, thực thể B vẫn ở đó? –

Trả lời

1

Từ kinh nghiệm, nghe thông báo khác ngoài NSManagedObjectContextDidSaveNotification là một mớ hỗn độn lớn và có thể dẫn đến việc dựa vào các thuộc tính chưa được cập nhật. Bộ điều khiển xem chi tiết phải nghe thông báo NSManagedObjectContextDidSaveNotification, được ném sau khi áp dụng thác. Sau đó bạn có thể kiểm tra bằng một vài phương tiện nếu đối tượng hiện tại là hợp lệ hay không (bạn có thể kiểm tra xem ngữ cảnh đối tượng được quản lý của đối tượng hiện tại là nil hay bạn có thể thực hiện tìm nạp và xem đối tượng tồn tại trong cửa hàng).

Các vấn đề liên quan