Question

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.

Answer 1

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 existing ProductGroup objects.

In pseudo-code it would look like:

Add a "synced" flag to ProductGroup entity in the data model

Set "synced" of every ProductGroup object to "false"
Extract data for a ProductGroup from server glob
Using data fetch for an existing ProductGroup object
If extracted data matches and existing ProductGroup object
  update existing ProductGroup object
  set synced of ProductGroup object to true
else
  create new ProductGroup object with data
  set synced of new ProductGroup object to true
Delete all ProductGroup objects where synced == false

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.