What questions should I ask myself to determine if I need a 'primary key' for my Core Data app?

Question

I'm building a simple app in Swift using Core Data and trying to decide if I should store a unique id in my entities. In my research, I have found examples of that do and examples that don't, but I haven't found any clear reasoning behind this kind of decision.

Please note: - I come from a RDBMS background and I know that Core Data is an object graph, not a relational db - I do know that Core Data creates an NSManagedObjectID, but how do I determine if that will be enough

I see threads like this (from 7 years ago, by the way) which lays out these options:

• Use -[NSManagedObject objectID]. Note that this ID is temporary until either the object is saved for the first time or you call
• [NSManagedObjectContext obtainPermanentIDsForObjects:error:] Use the CFUUID family of functions to generate a UUID for each object in your -awakeFromInsert method
• Create your own primary key-like system that stores an integer in your model and increments it with the creation of each object

but I haven't been able to find much information about which options are appropriate for which situations.

What questions should I be asking myself to figure out if Core Data's unique identifier (NSManagedObjectID) is all I need or if I should go beyond that and choose to include one of my own into the mix.

Answer 1

The only reason to use your own unique IDs with Core Data is if you ever sync the data to another device or web service. NSManagedObjectID is sufficient for local use but they don't work well for syncing. For example, if you get data from your back end server, it probably has unique IDs, but you can't force Core Data to use them. Likewise even if your syncing is to another iOS device, you can't force Core Data on the second device to use the same NSManagedObjectID as on the first.

For local use, NSManagedObjectID is all you need. If you need to save a reference to a managed object in user defaults, you can store that. Later you can use object(with:) or existingObject(with:) to quickly retrieve the managed object.

Answer 2

if Core Data's unique identifier (NSManagedObjectID) is all I need

Need for what purpose exactly?

Core Data maintains its object's primary keys internally, so you basically don't need to implement them yourself. In CD you interact with objects that already have a mechanism to establish relationships. You just have to assign one NSManagedObject to a property of another NSManagedObject and that will represent a O2O or O2M relationship like this:

anotherObject.parent = oneObject;

For many- side there will be a set for that. Have a look at the documentation.

The only scenario when you need some sort of foreign keys is when you syncing your data with some web-service.

You may be interested in this post if you need to store a reference to some particular NSManagedObject in user defaults.

And by the way, there is [[NSUUID UUID] UUIDString].