Does it make sense to have a primary key attribute in Core Data in iOS 9?

Question

Created Oct ’15

Replies 4

Boosts 0

Views 12k

Participants 4

In

iOS 9

, I can specify certain attributes in an entity to be

unique constraints

to prevent managed objects with the same unique constraints to be created.

Each

NSManagedObject

has its own

ObjectId

but maintained internally by

Core Data

and cannot be set as unique constraint in the model.

Based on that notion, does it make sense to include a "

primary key

" attribute for all entities in core data and specify the primary key as unique constraint if I don't want duplicate data?

Boost

Answer 1

NotMyName OP

Oct ’15

Shouldn't you be asking and answering that question for yourself?

Otherwise, the answer is "No, there's no reason to include a primary key attribute for every single entity that a person is going to create in Core Data. Because not everything has a primary key other than its object ID." If you create a field equivalent in meaning and function to the objectID, all you're doing is wasting space in the database.

0

Answer 2

john.estropia OP

Oct ’15

While I agree that each app should decide their need of a primary key or not, there is one thing that may force preferrence on a custom primary key than on the object ID. When a store migrates to a new version the object ID will change, so if you need bookkeeping using IDs you may be safer to have your own unique attribute.

0

Answer 3

NotMyName OP

Oct ’15

Isn't that the "Instead of updating the external references, let's just permenantly add another attribute to the table to do the same thing?" solution to the problem of the object ID's being updated during data store migration?

0

Answer 4

reflact OP

Oct ’15

Every entry generated by CoreData has its own unique ID respectively primary key in database table. You do not need to add your own but if you want you can by making it "Indexed" in Property Editor.

0