CoreData:从捆绑数据库迁移数据 [英] CoreData:Migrate data from bundled db

问题描述

我们的应用有一个基于单一核心数据模型的核心数据存储.有只读数据和读写数据.

Our app is having a coredata store which is based on a single coredata model. There are read-only data as well as read-write data.

只读数据与应用程序一起预加载和捆绑，因此在全新安装时，该数据库被复制到应用程序沙箱，然后通过网络服务更新数据库(即只有更改的数据将从网络服务中更新，从而减少传输的数据).

The read-only data are pre-loaded and bundled along with the app, so that on a fresh install, this database is copied to the application sandbox and from there on the data base will be updated via webservice (ie only the changed data will get updated from webservice so that less data is transferred).

现在我们需要为只读实体添加更多属性.

Now we have situation where we need to add more attributes to the read-only entities.

轻量级迁移将有助于轻松升级架构，但问题在于新数据，因为我们正在向所有只读实体添加新属性，所有数据记录都已更改，并且 Web 服务同步可能需要大量时间下载和更新数据.为了避免这种情况，我们将更新的数据与应用程序捆绑在一起(这将解决全新安装的问题).但是对于正在升级应用程序的用户，是否有一种标准机制可以从捆绑的数据库中复制只读实体并将其更新到沙箱中的现有数据库，以便他们获得更新的只读数据以及他们的读取- 写入数据保持不变.

Light weight migration will help in upgrading the schema easily, but the problem is about the new data, since we are adding new attributes to all the read-only entities, all the data records are changed and a webservice sync might take a lot of time to download and update data. To avoid this we are bundling the updated data along with the app ( this will solve the issue for a fresh install). But for the users which are upgrading the app is there a standard mechanism to copy the read-only entities from the bundled db and update those to the existing database in the sandbox so that they will get the updated read-only data and also their read-write data remains intact.

更新

这是场景，

我将 X.sqlite 与 proj(具有新架构)捆绑在一起，如果 X.sqlite 在 doc dir 中不存在，我将复制它，然后一切正常.现在在App更新场景中，X.sqlte已经存在于doc目录中，不会被复制，迁移助手会迁移schema.所以现在我们有 X.sqlite 在 doc dir 中有新模式但旧数据(没有新属性).现在我想知道是否有办法将捆绑的 X.sqlite 中的数据与 doc 目录中的数据合并.我想知道有没有合并的过程.

I have X.sqlite bundled with the proj (which has new schema), if X.sqlite is not there in doc dir I then copy it and from there everything works OK. Now in the App update scenario, X.sqilte will be already present in doc dir and won’t be copied and the migration assistant will migrate the schema. So now we have X.sqlite with the new schema in doc dir but old data (without new attributes). Now what I want to know is if there is a way to merge the data from bundled X.sqlite with the one which is there in the doc dir. I want to know if there is a process for merging.

更准确的

以下是实体

*商店 - 只读

*产品 - 只读

*ProductGroups - 只读

*ProductGroups - ReadOnly

*ShopList - 基于用户

*ShopList - User based

所有产品都在同一型号和同一家商店中.

All are in the same model and in the same store.

现在商店/产品/产品组有额外的属性.

Now Store/ Products / ProductGroups have extra attributes.

轻量级迁移器将迁移 X.Sqlite 的架构，以便数据库具有新的属性列.现在我关心的是下一步，

Lightweight migrator will migrate the schema of X.Sqlite so that the DB will have the new attribute columns. Now what I am concerned is the next step,

让我们以商店为例.Store 有两个新属性 latitude 和 logitude.现在的问题是如何复制数据?步骤

Lets take Store as an example. Store has two new attributes latitude and logitude. Now the question how to copy the data? the steps

将捆绑的数据库复制到具有差异名称的文档目录?创建一个新的持久性协调器?读取捆绑的数据并获取对象?然后遍历现有的数据库?

Copying the bundled DB to doc dir with diff name? Create a new persistance co-ordinator? Read the bundled data and get the objects? then iterate through the existing db?

推荐答案

好的 所以经过大量的研究我终于实现了我的目标，下面是我做的路径和解决方案

Ok So finally after a lot of research I achieved my goal, below are the trails and solutions that i did

溶胶 1

1. 在单独的数据库中拥有只读和读写数据，这样如果有任何主数据更新，我可以安全地删除只读数据库，我可以保护用户数据，但考虑到我的时间表和限制，这对我来说是不可能的.在此发帖以帮助他人.

溶胶 2

我想尝试将捆绑数据库中的新数据合并到现有数据库中，我想将现有数据库中的用户数据合并到新数据库中.下面是完成的步骤.--> 创建了一个新的数据上下文.

I thought rather trying to merge the new data from bundled DB to the existing DB, I thought of merging the user data from existing db to the new db. Below are the steps done. --> Created a new datacontext.

--> 创建了一个新的持久协调器

--> Created a new persistent co-ordinator

--> 用 _v2 重命名捆绑的 db 并将其复制到 Doc 目录，现在我们在 doc 目录中有 2 个 DB我拿了一些应用导入大数据集

--> Renamed the bundled db with _v2 and copied it to the Doc directory, now we have 2 DB in the doc dir I took some app Importing large data sets

--> 现在使用 ManagedObject 克隆类别，我将所有用户信息数据从现有数据库复制到新数据库 _v2.在此处找到类别 NSManagedObject+Clone

--> Now using the ManagedObject clone category, I copied all the user info data from the existing db to the new db _v2. Found the category here NSManagedObject+Clone

--> 工作正常，现在我的 _v2 数据库包含新的只读数据和旧数据库中的用户数据.

--> Worked fine, now I got my _v2 database with new readonly data and the user data from the old database.

--> 现在我需要将控制权交还给默认的数据上下文

--> Now I need to give control back to the default datacontext

--> 我尝试将旧上下文的 PSC 更改为新 PSC，但系统不允许我这样做.

--> I tried to change the PSC of the old context to the new PSC but system didnt allow me to do that.

--> 然后我尝试将旧上下文的持久性存储更改为新存储，但我收到错误消息说数据库已经存在.(migratePersistentStore:toURL:options:withType:error:)

--> I then tried to change the persistence store of the old context to the new store but I got error saying that database already exists. (migratePersistentStore:toURL:options:withType:error:)

--> 我的想法在这里用完了.

--> I ran out of ideas here.

溶胶 3

然后，我与其他一些同事讨论了我的问题，他们建议以不同的格式提供新数据，这让我感到震惊.正如我已经提到的，我的应用程序具有将新数据下载为 JSON 并将其合并到核心数据的逻辑，为什么我可以提供包含新数据的 JSON 文件以及我的应用程序?

I then discussed my problems with some of my other colleagues and they suggested to provide the new data in a different format and that striked. As I already mentioned, my app has logic to download new data as JSON and merge it to core data, why can I provide a JSON file with the new data, along with my app?

我从 webservice 收集了新的响应并创建了一个 JSON(不大，只有 1.5MB)并附有应用程序包，对于更新应用程序的用户，我将读取 JSON 数据而不是合并核心数据本地并进行初始合并到核心数据DB，数据库将拥有新的只读数据和完整的用户数据.初始合并后，一切都将由在线同步处理.

I collected the new response from thew webservice and created a JSON (not big just 1.5MB) and attached with app bundle, and for users that update the app, instead of core data merging I will read the JSON data locally and do the initial merging to the core data DB, there by the data base will have the new readonly data and also user data intact. After the initial merge, everything will be taken care by online sync.

这篇关于CoreData:从捆绑数据库迁移数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！