在 iOS 应用程序中同步核心数据数据库
我对核心数据迁移有疑问。
假设我有一个应用程序，表 A 中有一些预定义值。我想将其与另一个数据库（表 B）同步，这样当将新记录添加到表 B 时，该记录应该添加到我的表 A 中 我知道使用核心数据迁移，
当我向表中添加列时，我将能够访问添加列之前先前存储在旧表中的值。
我想知道如何使用另一个表上添加的记录来更新我的表。
更新：
来自下面的评论：
我想到的问题是…… 我想发布我的更新 应用程序。我被困在如何更新 现有的核心数据数据库也 存储用户输入的数据。所有我 需要做的是更新一些 记录并保存当前用户 数据。我该怎么做？
I have a doubt about Core Data migration.
Say I have an application which has some predefined values in a table A. I want to sync it with another database, with a table B in such a way that when new records are added totable B, that record should get added to my table A.
I know using Core Data migration, when I add columns to a table, I will be able to access the values previously stored in the older table before the addition of the column.
I would like to know how my table can be updated with the added records on another table.
Update:
From comment below:
The question I had in mind is this...
I want to release an update for my
app. I'm stuck on how to update the
existing Core Data database which also
stores data entered by the user. All I
need to do is update a couple of
records and preserve current user
data. How do I do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
核心数据不是 SQL。实体不是表。对象不是行。列不是属性。 Core Data 是一个对象图管理系统，它可能会也可能不会持久化对象图，并且可能会也可能不会在幕后使用 SQL 来执行此操作。尝试用 SQL 术语来思考 Core Data 将会导致您完全误解 Core Data，并导致很多痛苦和浪费时间。
那就是疯狂。
听起来您实际上并不想迁移，因为该术语在核心数据中使用。核心数据中的迁移意味着从数据图持久存储的早期版本迁移到相同版本的较新版本。
例如，在 1.0 版本中，您有一个实体
Person，其属性为firstName和lastName。应用发布后，您希望更新到 2.0 版本并向Person实体添加phoneNumber属性。您可以使用迁移将用户现有的对象图和持久存储更新为新的对象图。如果“表”实际上指的是实体，那么您可以将实体以某种关系链接在一起，以便它们可以互相监视。如果“表”指的是数据模型或持久存储，那么答案会更复杂。可以使用配置、获取的属性、UUID 等来完成，但在跳过所有这些步骤之前，您必须了解真正需要做什么。
Core Data is not SQL. Entities are not tables. Objects are not rows. Columns are not attributes. Core Data is an object graph management system that may or may not persist the object graph and may or may not use SQL far behind the scenes to do so. Trying to think of Core Data in SQL terms will cause you to completely misunderstand Core Data and result in much grief and wasted time.
That way lies madness.
It sounds like you don't actually want to migrate as the term is used in Core Data. Migration in Core Data means moving from an earlier version of a data graph's persistent store to a newer version of the same.
E.g. In the 1.0 version you have an entity
Personwith the attributesfirstNameandlastName. After the app has been release you wish to update to the 2.0 version and add aphoneNumberattribute to thePersonentity. You would use migration to update the user's existing object graphs and persistent stores to the new object graph.If by "table" you actually mean entities, then you can link entities together in a relationship so that they can watch each other. If by "table" you mean a data model or persistent store, then the answer is more complex. It can be done using configurations, fetched attributes, UUIDs etc but you must understand what you really need to do before you jump through all those hoops.