更新应用程序以使用之前双 SQLite 持久存储中的核心数据
我目前正在升级一个较旧的 iPhone 抽认卡应用程序，该应用程序使用两个 SQLite 数据库（一个包含只读问题，只能通过应用程序更新、删除卡片、添加卡片、更新卡片进行更新，另一个包含用户添加其自己的自定义卡）以使用 Core Data 代替。 “Flashcard”对象区分只读卡和用户添加卡的唯一属性是“isCustom”属性。以下是我认为执行此操作所需的步骤：（
首先从 2 个 SQLite 数据库更新到 CoreData）
- 从用户自定义卡数据库获取所有自定义卡条目。
- 添加带有只读卡的新 Core Data 对象模型，然后 将用户添加的自定义卡加载到该模型中。
- 删除旧的 SQLite 数据库（自定义卡数据库和只读卡 分贝）。
（将来的更新将已经具有核心数据模型）
- 从当前核心数据持久存储中获取所有自定义卡。
- 将所有自定义卡迁移到新的核心数据持久存储。
我只是想在开始从头开始设计这个系统之前确定这是否是正确的方法。任何提示将不胜感激。
I'm currently upgrading an older iPhone flashcard application that uses two SQLite dbs (one with read-only questions that can only be updated by app updates, deletion of cards, addition of cards, updates to cards, and another one where user added their own custom cards) to use Core Data instead. The only property for the "Flashcard" object that distinguishes between a read only card and user added card is the "isCustom" property. Here are the steps that I believe are necessary to do this:
(First update from 2 SQLite dbs to CoreData)
- Get all custom card entries from the user custom card db.
- Add new Core Data object model with read only cards, and then
load in user added custom cards to this model. - Delete old SQLite databases (custom card db and read only card
db).
(Updates in the future that will already have a Core Data model)
- Get all custom cards from the current Core Data persistent store.
- Migrate all custom cards to new Core Data persistent store.
I just want to make sure if this is the way to go before I start designing this system from the ground up. Any tips will be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您没有理由不能仍然维护两个核心数据存储：一个是只读的，用于存储随应用程序一起提供的内容，另一个是可写的，用于存储自定义条目。我在我的一个应用程序中执行此操作，它允许我轻松更新每个版本附带的数据库。
我在不同的上下文下管理两个不同的持久性存储，但您也可以将多个持久性存储附加到同一个持久性存储协调器，以使它们位于同一上下文中。
请注意，如果您对只读核心数据持久性存储使用相同的模型，或者将只读数据包含在一个中央持久性存储中，则每次您都需要将该非自定义数据迁移到新模型。更新一下。与您的应用程序一起提供单独的只读核心数据存储将使您可以在自己的一端进行一次迁移，而不是让每个最终用户在模型更新时在现场进行迁移。
There's no reason that you can't still maintain two Core Data stores: one read-only for your content that you ship with your application, and one that's writable for your custom entries. I do this within one of my applications, and it allows me to easily update the database I ship with each version.
I manage my two different persistent stores under separate contexts, but you can also attach multiple persistent stores to the same persistent store coordinator to have them both be on the same context.
Note that if you use the same model for your read-only Core Data persistent store, or include the read-only data in one central persistent store, you'll also need to migrate that non-custom data to the new model every time you update that. Shipping a separate read-only Core Data store with your application would let you do that migration once on your end, rather than having each one of your end users do that migration in the field on a model update.