核心数据中的关系完整性和验证iCloud同步 [英] Relational Integrity and Validation in Core Data iCloud Syncing

查看:180
本文介绍了核心数据中的关系完整性和验证iCloud同步的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

考虑下面的简单实体模型:实体A与实体B具有称为 b 的一对一关系。实体B具有称为 a 的逆对一关系。这两种关系都不是可选的。

  A B 
b< -----> a

假设我们有两个设备(1)和(2)开始完全同步。每个都有一个类A的对象和一个类B的对象,它们彼此相关联。在设备1上,我们有对象A1和B1,在设备B上有相同的逻辑对象A1和B1。



现在假设在每个设备上进行模拟的更改:


在设备1上,我们删除B1,插入B2,并将A1与B2关联。然后
保存更改。
在设备2上,我们删除B1,插入B3,并将A1
与B3关联。然后保存更改。


设备1现在尝试从设备2导入事务日志。将插入B3,A1将关联与B3。到目前为止这么好,但是B2现在剩下的关系 a 等于 nil 关系是非可选的,因此发生验证错误。



设备2上会发生类似情况,因为有两个B对象,只有一个A对象要关联。因此,必须始终存在验证错误,因为B对象之一必须将 a 关系设置为 nil



<更糟糕的是,任何未来的变化总会留下一个错误的B对象,因此将失败验证。实际上,用户不能通过重置关系本身来解决问题。



问题是,如何解决这样的验证错误?这一切发生在触发 NSPersistentStoreDidImportUbiquitousContentChangesNotification 通知之前。它不是您的应用程序main NSManagedObjectContext 中的验证错误,它是在将事务日志初始导入持久存储库期间发生的验证错误。



我可以想到的唯一选择是尝试在自定义安装程序( setA:)中删除无效的B对象, B类本身的KVC验证方法( validateA:error:),因为这些似乎是在事务日志导入期间触发的。但我不知道这样的副作用是允许的,当我尝试它,它似乎导致讨厌的日志消息的效果。



任何人知道

解决方案

在Apple的开发者论坛上查看这个线程:



https://devforums.apple.com/message/641930#641930



Apple员工有回应。简而言之:



1)这是Core Data iCloud在当前版本的iOS(5.1)和OS X(10.7.3)下同步的已知错误。 p>

2)如果关系对于验证谓词是非可选的,则同步将完全停止。所以你需要删除对时间的验证以保持流动。但是,这样做会使设备的数据不匹配。



3)没有正式的解决方法。一种很麻烦的方法是维护一个跟踪关系的单独属性。然后,你需要扫描通过iCloud更改的任何对象,并修复关系,如果它是nil。



我也被这个bug咬了。非常令人沮丧的处理遇到麻烦的客户。希望苹果的解决方案很快就会... ...


Consider the following simple entity model: Entity A has a to-one relationship to Entity B called b. Entity B has an inverse to-one relationship called a. Neither relationship is optional.

A            B
b  < ----- > a

Assume we have two devices (1) and (2) that begin fully synced. Each has one object of class A, and one object of class B, and they are associated with one another. On device 1, we have objects A1 and B1, and on device B we have the same logical objects A1 and B1.

Now assume that simulateous changes are made on each device:

On device 1, we delete B1, insert B2, and associate A1 with B2. Then save changes.
On device 2, we delete B1, insert B3, and associate A1 with B3. Then save changes.

Device 1 now attempts to import the transaction logs from device 2. B3 will be inserted, and A1 will be associated with B3. So far so good, but B2 is now left with relationship a equal to nil. The a relationship is non-optional, so a validation error occurs.

Something similar will occur on device 2, because there are two B objects, and only one A object to be associated with. There must thus always be a validation error, because one of B objects must have an a relationship set to nil.

Even worse, any future change will always leave an errant B object hanging around, and so will fail validation. In effect, the user cannot fix the problem themselves by resetting the relationship. It is permanently broken.

The question is, how can you address a validation error like this? This all happens before the NSPersistentStoreDidImportUbiquitousContentChangesNotification notification is triggered. It is not a validation error in your apps main NSManagedObjectContext, it is a validation error that occurs during the initial import of transaction logs into the persistent store.

The only option I can think of is perhaps to try to delete the invalid B object in a custom setter (setA:), or in a KVC validation method (validateA:error:) on the B class itself, because these do seem to be triggered during the transaction log import. But I'm not sure that side effects like these are allowed, and when I try it, it does seem to result in nasty log messages to that effect.

Anyone know what the right way to handle this is?

解决方案

Check out this thread on Apple's Developer Forums:

https://devforums.apple.com/message/641930#641930

There is a response from an Apple employee. In a nutshell:

1) This is a known bug in Core Data iCloud syncing under current versions of iOS (5.1) and OS X (10.7.3).

2) If the relationship is non-optional with a validation predicate, syncing will cease completely. So you will need to remove the validation for the time-being to keep things flowing. However, doing so will leave the devices with mismatched data.

3) There is no official workaround for this. One approach, which is messy, would be to maintain a separate attribute which tracks the relationship. Then, you would need to scan through any objects changed via iCloud and fix the relationship if it is nil.

I am also bitten by this bug. Very frustrating to deal with customers who run into troubles. Hopefully a fix from Apple with be out soon...

这篇关于核心数据中的关系完整性和验证iCloud同步的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆