【问题标题】:Multiple Persistent Store Coordinator Core Data多个持久存储协调器核心数据
【发布时间】:2014-05-01 12:30:27
【问题描述】:

目前我有一个由 sql 数据库备份的 Persistent Store Coordinator。我有很多实体。当我更改模型时,我尝试使用轻量级迁移。如果它失败了,我只是删除所有内容并重新设置。现在这工作正常。现在假设我必须保存一些书签。由于您可以拥有多个书签,我认为最好将其与核心数据一起保存。但是在这种情况下,我需要一个真正的迁移策略,这样用户就不会丢失其书签。

我正在考虑创建一个单独的持久存储协调器,它只包含书签实体。有了这个,我可以在必要时进行迁移,而另一个持久存储可以按原样使用而无需迁移。

这可能并推荐吗?或者有什么我需要注意的陷阱。我希望我能正确解释我的情况。我也在考虑用 NSCoding 保存书签,但我不确定在这种情况下哪个会更好。

感谢任何帮助。

【问题讨论】:

  • 您是否将作为应用程序一部分提供的静态内容与他们可以自己修改的用户内容分开?
  • 你这是什么意思?当我的应用程序开始获取第一个持久存储的所有数据时,我正在发出服务器请求。因此,如果数据消失了,那也没那么糟糕,因为无论如何我都会得到这些东西。

标签: ios objective-c core-data


【解决方案1】:

完全有可能。将刚刚从服务器下载的静态数据(因为不应该备份)和用户创建的数据(应该备份)分开当然是个好主意。

您的主要缺陷在于确保将商店/上下文分开,并且您的代码正确命名事物,以便清楚您正在使用的内容。

如果您只有几个书签,它们很小并且通常同时加载,那么NSCoding 是一个不错的选择。如果你有很多,它们很大或不经常加载,那么这不是一个很好的选择。

【讨论】:

  • 谢谢。我还将有一个选项可以为这个书签设置一个布尔值。我可能需要为此进行不同的查询。可以手动完成,但我想最好使用核心数据。也许我会使用 NSCoding,如果事情变得更复杂,我也可以将其移至核心数据。
  • 查询功能听起来是使用 Core Data 选项的好理由。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-02-03
  • 1970-01-01
相关资源
最近更新 更多