So far in order to use Core Data, we have been using Xcode's template that comes in the AppDelegate. We could leave it as it is and the app's functionality won't be affected. But if we really want to know the details of what's happening, we could implement our own Core Data stack.
This helps in two ways:
- we get to learn about how Core Data works in detail
- we get better separation of concerns (the AppDelegate shouldn't be responsible of initializing all the things).
- Create our own Core Data Stack.
- Subclassing NSManagedObject for entities.
- Use the model editor to create relationships between properties.
- Identify different types of relationships.
Let's remember the components that make up the Core Data stack:
- NSManagedObjectModel Represents each object type in the data model, along with its properties and relationships.
- NSPersistentStore Reads and writes data to the storage we want. Core Data gives us four types of NSPersistentStore: three atomic and one non-atomic.
- NSPersistentStoreCoordinator Bridge between the managed object model and persistent store.
Uses the model and persistent stores to do the hard work.
Hides implementation details of the store. In this way the NSManagedObjectContext doesn't care the type of store or how many there are.
- NSManagedObjectContext
We ALWAYS need one of these to work with Core Data.
- This is a scratchpad for working with our managed objects.
- All the work done with objects happens here and changes won't affect data until we call save on the context.
- Manages the lifecycle of objects (relationships and validation)
- Every object keeps a reference to its context, can't exist without one.
- NSPersistentContainer Container that holds everything together (the managed model, the store coordinator, persistent store and managed context)
A relationship describes how an entity affects another entity. At minimum, a relationship specifies:
- Name
- Destination entity
- Delete rule
- Cardinality type (To One or To Many)
- Settings for whether the relationship should be saved in the store (transient)
- Whether it is required to have a value when saved (optional).
You should also configure every relationship with an inverse relationship.
Use To One relationships to connect the source with a single instance of the destination type.
Use To Many relationships to connect the source with a mutable set of the destination type.
Each relationship points from a source entity (the entity whose relationships you’re editing) to a destination entity. The destination entity is a related type that affects and is affected by the source type.
Setting the same source and destination types creates a reflexive relationship.
For example, an Employee may manage another Employee.
- Are not saved to the persistent store.
- Useful to store temporary values.
- Core Data tracks the changes to these values for undo purposes.
Are not required to have instances of their destination type. In contrast, a required relationship must point to one or more instances of the destination type.
ManagedObject relationships are inherently bidirectional.
What does that mean?
If a User has many Tweets, then a Tweet can have one(Belong to one) User.
Model relationships in both directions; CoreData uses that to ensure consistency of its objects.
Instructions here
- Walkthrough the creation of Entities, Attributes and Relationships can be found here
- Configuring entities here
- Configuring attributes here
- Configuring relationships here
- Modern Core Data article
- Theory and activity based on content from “Core Data by Tutorials.” By Pietro Rea.
- Relationships