0

I'm looking to serialize a collection of Core Data objects (probably into JSON) and have been doing reading on the subject. I'll likely be serializing/deserializing JSON data as a means of allowing iOS users to easily export and re-import their data. This could be a case of backing up and restoring on the same device, or importing the data onto an entirely new device.

My main question at this point is how I handle the identification of existing data during import. If I'm reimporting objects that already exist in the store I'd ideally like to update them. Likewise, I'd like to leave any existing data that's not included in the import alone. What's the best practice in this situation? Should I assign each NSManagedObject a unique ID as and when it's created and compare this ID when determining whether an object is equal?

I'm aware that each NSManagedObject has an objectID assigned to it, but I'm not entirely sure I can rely on this given that exported data could be imported onto an entirely separate device (where objectID's could well collide or, more likely, the object would be assigned a new objectID upon creation).

Community
  • 1
  • 1
ndg
  • 2,585
  • 2
  • 33
  • 58
  • Each core datea object has a unique id which does not change once the object is persistent for the first time. So make sure that you save the context before exporting all objetcts as JSON or whatever to insure that any transient object is made persistent and gets its unique id. On the re-import you can use these ids to identify identical objects. Hope ths answers your question. Because it is a bit more complex. Data and objects referred to may have changed in the meantime referred objects may have been created (easy) and referred objects may have been deleted in the meantime (not that easy). – Hermann Klecker Mar 30 '13 at 13:44
  • I'm not entirely sure I can rely on an NSManagedObject's objectID given that exported data could be reimported onto an entirely separate device (where objectID's could well collide or, more likely, the object would be assigned a new objectID upon creation) - which is why I was asking whether it's best practice to generate and maintain your own unique identifier for each object. – ndg Mar 30 '13 at 13:50
  • Well, I never did that myself. Yes, on a different device the IDs could collide, although that is quite unlikely if not implossible given the nature of these IDs. Yes, upon creation of the imported object a new ID would be assigned. Before you actually create a new object you can check whether an object of that ID exists already. If not, then you create one. If yes then you need to deal with potential changes (Maybe you just don't do anything, depending on business requirements. More difficult is though when you import an object that has been deleted in the meantime. – Hermann Klecker Mar 30 '13 at 15:09

1 Answers1

1

How do I handle the identification of existing data during import?

I would assign my own unique identifier for each item so an import/sync/export would be posible for other architectures as well (you might also need to include versioning information). This will allow identification of objects across devices.

You cannot rely on the objectID when exporting to other devices:

There is no way to create a managed object with a specific object id ( see here ), this would make it imposible to avoid assigning you own identifier to use for import/sync/export (unless you upload/download the entire DB file to the other device).

Bear in mind, Uniquing (primary key) in CoreData is not trivial and might effect performance if not done correctly.

Community
  • 1
  • 1
Dan Shelly
  • 5,991
  • 2
  • 22
  • 26
  • I suspected this may be the case. From a bit of Googling [this](http://stackoverflow.com/a/903778/274405) seems to be close to the money: use the CFUUID family to generate a guaranteed unique string and index that in the MOM. That would mean only determining unique-ness when importing data (rather than during the creation of each NSManagedObject). But you mention other potential performance hits. Care to shed any light on what these may be? – ndg Mar 30 '13 at 17:39
  • for example, if you have many items fetched from a server, some might already exist and some might not. you should not try and validate their existence one by one, but instead, collect their identifiers and fetch what you already have in one go, update these and create the rest, only then save (2 trips to the store instead of one per item). – Dan Shelly Mar 30 '13 at 18:44
  • Gotcha, I see. I thought you were referring to scalability. I'll mark this as answered. Thanks for your help. – ndg Mar 30 '13 at 18:49