iPhone:如何通过外键管理核心数据关系
我有一个应用程序可以在服务器端和 iOS 客户端上使用数据库。我使用 HTTP 服务在服务器端的 SQL Server 和 iPhone 上的 Core Data 之间进行同步。
我有一些像这样的核心数据对象:
ProductGroup
Attributes:
id
Relationships:
products
Product
Attributes:
id
productGroupId
Releationships:
productGroup
由于服务器的限制,我无法使用增量同步。当我同步数据时,(例如)我必须删除所有 ProductGroup 对象,从服务器获取响应,然后创建新的对象(以及一些旧的对象)。
问题是,如果我有一个 productA
属于 productGroupB
,通常我可以执行 productA.productGroup
,但是在删除 productGroupB 后
并创建另一个具有相同内容的内容,关系就会丢失。
所以我想知道是否有任何方法可以通过 FK 来管理关系,就像 .NET 中的实体框架一样,这样我在重新创建后仍然可以找到关系另一端的对象。
I have an app working with databases on both server side and iOS client side. And I use a HTTP services to sync between SQL Server on server side and Core Data on iPhone.
I have some Core Data objects like this:
ProductGroup
Attributes:
id
Relationships:
products
Product
Attributes:
id
productGroupId
Releationships:
productGroup
Due to the limit of the server, I can't use incremental sync. When I sync my data, (for example) I have to delete all ProductGroup objects, get response from server, then create new ones(and some old ones again).
The problem is, if I have a productA
belongs to productGroupB
, usually I can do productA.productGroup
, but after I delete productGroupB
and create another one with the same content, the relationship is lost.
So I am wandering is there any way to manage relationships by FKs, like the Entity Framework in .NET, so I can still find the object on the other end of the relationship after re-create.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
当您删除
ProductGroup
对象时,您会丢失这种关系,因为 Core Data 不是 SQL。在关系的情况下,Core Data 并不关心关系另一端对象的属性,它只针对特定的对象。您可以拥有任意数量的具有完全相同属性但不同关系的对象,并且这些对象将完全不同。核心数据关系不是 SQL 连接或键,而是对特定托管对象的持久指针式引用。删除对象,指针也必须消失。为了实现您想要的目的,您可以使用获取的属性,该属性将动态获取
Product.id
属性。然而,这是一种相当笨拙的做事方式。在这种情况下,您不必求助于获取的属性。我认为你需要重新考虑你的设计。我从未见过您必须删除实体/类的每个实例才能添加或删除对象的情况。实际上,您实际上无法一次性做到这一点。相反,您必须获取对象,然后将它们一一删除。您可能需要检查每个对象是否需要删除或更新。
听起来您从服务器收到了大量 SQL 格式数据,并且您认为必须从头开始构建对象图。你真的不应该这样做。无论如何,您都必须解析数据以创建新的
ProductGroup
对象,因此您应该使用该解析的结果来更改现有的ProductGroup
对象。在伪代码中,它看起来像:
这里要记住的重要一点是您正在处理对象而不是表、列、行或联接。熟悉 SQL 的人通常认为 Core Data 只是 SQL 的对象包装器。它不是。它是一个对象图管理器,可能会也可能不会在幕后使用 SQL 将对象图持久保存(冻干)到磁盘。
你必须始终以对象来思考。您在使用 SQL 时形成的直觉更有可能让您误入歧途,而不是在核心数据方面为您提供帮助。
You lose the relationship when you delete the
ProductGroup
objects because Core Data isn't SQL. In the case of relationships, Core Data cares nothing about the attributes of the object on the other side of the relationship, it just targets a specific object. You can have an arbitrary number of objects with the exact same attributes but different relationships and the objects will be completely distinct. A Core Data relationship is not an SQL join or key but a persisted pointer-like reference to a specific managed object. Delete the object and the pointer has to go as well.To accomplish what you want, you could use a fetched property which would fetch on the
Product.id
attribute dynamically. However, that is a fairly clumsy way of doing things. You shouldn't have to resort to a fetched property in this instance.I think you need to rethink your design. I have never seen a case where you had to delete an every instance of an entity/class just to add or remove objects. As a practical matter, you can't actually do that in one go. Instead you have to fetch the objects and then delete them one-by-one. You might has well check each object for if it needs to be deleted or updated while you are at it.
It sounds like you receive a great glob of SQL format data from the server and you think you have to build the object graph from scratch. You really shouldn't have to. You have to parse the data to create new
ProductGroup
objects anyway, so you should use the results of that parsing to alter the existingProductGroup
objects.In pseudo-code it would look like:
The important thing to remember here is that you are dealing with objects and not tables, columns, rows or joins. People skilled in SQL often assume that Core Data is just an object wrapper around SQL. It is not. It is an object graph manager that may or may not use SQL far behind the scenes to persist (freeze dry) the object graph to disk.
You have to think in objects always. The intuitions you've developed for working with SQL are more likely to lead you astray than help you with Core Data.