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

问题描述

我们的应用程序有一个coredata存储，它基于一个核心数据模型。有只读数据以及读写数据。

只读数据是与应用程序一起预先加载并捆绑在一起的，所以在一个新的安装，这个数据库被复制到应用程序沙箱，从那里的数据库将通过webservice更新（即只有更改的数据将从webservice更新，使更少的数据传输）。

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

轻量级迁移将有助于轻松升级模式，但问题是关于新数据，因为我们正在向所有只读实体添加新属性，所有数据记录都会更改，并且Web服务同步可能需要很长时间才能下载和更新数据。为了避免这种情况，我们将绑定更新的数据与应用程序（这将解决新的安装的问题）。但是对于正在升级应用程序的用户来说，有一个标准的机制来从捆绑的数据库复制只读实体，并将它们更新到沙箱中的现有数据库，以便他们获得更新的只读数据以及它们的读取

更新方案，

我有X.sqlite捆绑的proj（它有新的模式），如果X.sqlite不在doc中，我然后复制它和从那里一切正常。现在在应用程序更新方案中，X.sqilte将已经存在于doc目录中，不会被复制，迁移助手将迁移模式。所以现在我们有X.sqlite与doc dir中的新模式，但旧的数据（没有新的属性）。现在我想知道的是，如果有一种方法来合并来自捆绑的X.sqlite的数据与在doc中的那个dir。我想知道是否有合并的过程。

更准确

以下是实体

：

*商店 - ReadOnly

*产品 - ReadOnly

* ProductGroups - ReadOnly

* ShopList - 基于用户

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

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

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

使用diff名称将捆绑的数据库复制到doc dir？
创建一个新的持久化协调器？
读取捆绑的数据并获取对象？
然后遍历现有的db？

解决方案

Ok所以最后经过很多研究我实现了我的目标，

Sol 1

$ b b
1. 在单独的数据库中具有只读和读写数据，因此，如果有任何主数据更新，我可以安全地删除只读数据库，并且我可以保护用户的数据，但考虑到我的时间表和约束，它不可能为我。
   Sol 2
   
   
   
   
   b $ b

   我认为，试图将新数据从捆绑的数据库合并到现有的数据库，我想到将用户数据从现有的数据库合并到新的数据库。下面是完成的步骤。
   - >创建一个新的数据报文。

   
   
   

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

   
   
   

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

   
   
   

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

   
   
   

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

   
   
   

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

   
   
   

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

   
   
   

   - >然后我试图更改旧上下文的持久存储到新的商店，但我错误说该数据库已存在。 （ migratePersistentStore：toURL：options：withType：error：）

   
   
   

   - >

   
   
   

   Sol 3

   
   
   

   然后我讨论了我的一些同事的问题他们建议以不同的格式提供新的数据并进行删除。正如我已经提到的，我的应用程序有逻辑下载新数据作为JSON，并将其合并到核心数据，为什么我可以提供一个JSON文件的新数据，以及我的应用程序？

   
   
   

   我从thew webservice收集了新的响应，并创建了一个JSON（不大只是1.5MB）并附加了应用程序包，对于更新应用程序的用户，而不是核心数据合并，我将读取 JSON数据本地并做初始合并到核心数据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.

   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.

   UPDATE

   Here is the scenario,

   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.

   To be more precise

   Below are the entities

   *Store - ReadOnly

   *Products - ReadOnly

   *ProductGroups - ReadOnly

   *ShopList - User based

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

   Now Store/ Products / ProductGroups have extra attributes.

   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,

   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

   Sol 1

   1. Have the read-only and read-write data in separate databases, so that I can safely delete the readonly db if there is any master data update and I can safeguard user's data, but considering the timelines and constraints that I have, it wont be possible for me. Posting here so that it might help others.

   Sol 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

   --> 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

   --> 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

   --> 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

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

   --> 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.

   Sol 3

   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?

   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屋！