核心数据,无反比关系
Core Data, No Inverse Relationship
我正在努力消除代码库中的大量警告,形式如下:
Entity.relationship should have an inverse.
总的来说,虽然我们的代码没有通过这些逆函数到达,但不管怎样把它们放在里面听起来是个好主意。
我的问题是我将如何做到这一点。
我应该通过轻量级迁移来进行这些更改吗?也就是说,我应该创建另一个 xcdatamodel 吗?
对于给定的数据模型,如果我们已经有多个 versions/migrations 怎么办?例如假设我们有 ReportsDataModel。在其下方是 ReportsDataModel1、ReportsDataModel2 和 ReportsDataModel3。似乎 XCode 7 在每个数据模型上都给我相同的警告。因此,如果我在向 ReportsDataModel4 的轻量级迁移中修复它们,它似乎不会摆脱以前的警告。
解决此问题的推荐方法是什么?
-Arjun
首先,您应该实现反向关系是正确的,因为 Xcode 需要它们。这是一个很好的数据库实践,如果您不使用它们,您几乎可以忽略多余的关系。
是的,您应该能够执行轻量级迁移,即创建新的数据模型并让Xcode推断更改。 Here, Apple states轻量级迁移支持添加关系
关于你的第二个问题,是的,创建另一个数据模型实际上并不能解决旧模型中的警告。您必须将旧模型保留在 Xcode 中,以便它可以计算轻量级迁移过程。如果您擦除模型并且用户从使用该模型的旧版本更新,他们的数据将被破坏。 (但是,如果您尚未发布具有特定数据模型的应用程序版本,则可以删除该数据模型。)
不过,你可以试试suppressing the inverse relationship warning entirely。
- 在 Xcode 中,单击您的项目文件。
- 单击
Build Settings
选项卡。
- 搜索
MOMC
。
- 将
Suppress momc warnings on missing inverse relationships
设置为是。
编辑 关于仅删除旧模型的警告:This question 建议您可以将旧数据模型移出 Xcode 并且将它放在别处,并向构建阶段添加一个复制文件操作,以便在编译时将文件复制回来。这样,文件及其无关的警告就不会妨碍您。抱歉,没有更少的 "hacky" 解决方案。
我正在努力消除代码库中的大量警告,形式如下:
Entity.relationship should have an inverse.
总的来说,虽然我们的代码没有通过这些逆函数到达,但不管怎样把它们放在里面听起来是个好主意。
我的问题是我将如何做到这一点。
我应该通过轻量级迁移来进行这些更改吗?也就是说,我应该创建另一个 xcdatamodel 吗?
对于给定的数据模型,如果我们已经有多个 versions/migrations 怎么办?例如假设我们有 ReportsDataModel。在其下方是 ReportsDataModel1、ReportsDataModel2 和 ReportsDataModel3。似乎 XCode 7 在每个数据模型上都给我相同的警告。因此,如果我在向 ReportsDataModel4 的轻量级迁移中修复它们,它似乎不会摆脱以前的警告。
解决此问题的推荐方法是什么?
-Arjun
首先,您应该实现反向关系是正确的,因为 Xcode 需要它们。这是一个很好的数据库实践,如果您不使用它们,您几乎可以忽略多余的关系。
是的,您应该能够执行轻量级迁移,即创建新的数据模型并让Xcode推断更改。 Here, Apple states轻量级迁移支持添加关系
关于你的第二个问题,是的,创建另一个数据模型实际上并不能解决旧模型中的警告。您必须将旧模型保留在 Xcode 中,以便它可以计算轻量级迁移过程。如果您擦除模型并且用户从使用该模型的旧版本更新,他们的数据将被破坏。 (但是,如果您尚未发布具有特定数据模型的应用程序版本,则可以删除该数据模型。)
不过,你可以试试suppressing the inverse relationship warning entirely。
- 在 Xcode 中,单击您的项目文件。
- 单击
Build Settings
选项卡。 - 搜索
MOMC
。 - 将
Suppress momc warnings on missing inverse relationships
设置为是。
编辑 关于仅删除旧模型的警告:This question 建议您可以将旧数据模型移出 Xcode 并且将它放在别处,并向构建阶段添加一个复制文件操作,以便在编译时将文件复制回来。这样,文件及其无关的警告就不会妨碍您。抱歉,没有更少的 "hacky" 解决方案。