Swift – Core Data – Part 1 | Relationships | Delete Rules

What is core data?

  1. Core Data is a object graph management and persistence Framework”. Core Data is a framework that you use to manage the model layer objects in your application.It provides generalized and automated solutions to common tasks associated with object life cycle and object graph management, including persistence.”
  2. Core Data is a model layer technology. Core Data helps you build the model layer that represents the state of your app. Core Data is also a persistent technology, in that it can persist the state of the model objects to disk.”
  3. It’s focus is on objects rather than the traditional table-driven relational database approach. When storing data, you are actually storing an object’s contents, where an object is represented by an Objective-C/Swift class that inherits the NSManagedObject class. A typical application will have several objects used together, forming an object graph.”
  4. Most imp point A Core Data consist of following stack objects:

    • a managed object model
    • a managed object context
    • a persistent store coordinator
    • a persistent store (storage)

Core Data Stack

A Core Data stack consist of following objects:

  • a managed object model
  • a managed object context
  • a persistent store coordinator
  • a persistent store (storage)

Managed Object Model

  • An object that is an instance of NSManagedObjectModel. An NSManagedObjectModelobject describes a schema, a collection of entities (data models) that you use in your application. It uses a private internal store to maintain its properties and implements all the basic behavior required of a managed object.

For Example in the attached screen shot Organization is managed object model and it contains internal properties/attributes like id and name.

 

  • The managed object model represents the data model of the application. 
  • An object that describes a schema—a collection of entities (data models) that you use in your application.
  • Even though Core Data isn’t a database, you can compare the managed object model to the schema of a database, that is, it contains information about the models or entities of the object graph, what attributes they have, and how they relate to one another.
  • The managed object model is an instance of NSManagedObjectModel and describes the schema used in your Core Data application. It is loaded from the model file which contains all the entity descriptions with their attributes and relationships that you defined in the Core Data Model inspector. So the model describes your objects.

Managed Object Context

A managed object should always be associated with a managed object context. There are no exceptions to this rule. Remember that a managed object context manages a number of records or managed objects. Managed Object Context is instance of class “ManagedObjectContext”.

 

Persistent Store Coordinator

The persistent store coordinator is the glue of the Core Data stack. It keeps a reference to the managed object model and the managed object context. And, as the name implies, the persistent store coordinator is in charge of the persistent store of the application.

A coordinator that associates persistent stores with a model (or a configuration of a model) and that mediates between the persistent stores and the managed object contexts.

Persistent Store Coordinator are actually the instances of “NSPersistentStoreCoordinator” class.

Persistent store

A persistent store is a repository in which managed objects may be stored. You can think of a persistent store as a database data file where individual records each hold the last-saved values of a managed object. Core Data offers three native file types for a persistent store: binary, XML, and SQLite. From the above screen shot you can see persistent store coordinates with Persistent store coordinator.

Object Graph

In computer science, in an object-oriented program, groups of objects form a network through their relationships with each other—either through a direct reference to another object or through a chain of intermediate references. These groups of objects are referred to as object graphs.

An object graph is a view of an object system at a particular point in time. 

Object-oriented applications contain complex webs of interrelated objects. Objects are linked to each other by one object either owning or containing another object or holding a reference to another object to which it sends messages. This web of objects is called an object graph.

Examples:

An array object that contains a single string object represents a small, simple object graph.

A group of objects containing an application object, with references to the windows, menus and their views, and other supporting objects, may represent a large, complex object graph.

Data Model

LIBRARY DATA MODEL

The Library entity has two attributes, name and location, both of type String. The Author entity also has two attributes, firstName and lastName, both of type String. The Book entity has three attributes, title of type StringpublicationDate of type Date, and pages of type Integer 16. This is what the data model should look like in the data model graph.

 

RELATIONSHIPS

A relationship specifies the entity, or the parent entity, of the objects at the destination.

TO-ONE RELATIONSHIPS —>

A book belongs to a library. This means that we need to create a relationship that links a book to a library.

Steps :

  1. Open Library.xcdatamodeld and switch to the editor’s table style.
  2. Select the Book entity.
  3. Click the plus button at the bottom of the Relationships table to add a relationship to the entity.
  4. Set Relationship to library and Destination to the Library entity. Leave Inverse empty for now.
  5. Switch to the editor’s graph style to visual representation of the relationship we defined.

We can conclude below points :

  1. The relationship is to-one relationship.
  2. A book can belong to one library only.
  3. The single arrow is pointing from book entity to library entity.
  4. There is no arrow pointing back from Library to Book, so there is no inverse relationship. It means that the library the book belongs to does not know that the library belongs to this book.

How to make a relationship system where library knows what books it contains. We have following relationship :

INVERSE RELATIONSHIPS <—->

Steps :

  1. Switch to editor’s table style and select the Library entity.
  2. Add a relationship named books.
  3. Set Destination to Book and set Inverse to library.

Switch to the data model graph to see what that looks like. The connection between Library and Book contains arrows pointing to and from each entity. See :

TO-MANY RELATIONSHIPS —>>

Ideally a library should have more than one books. Steps :

  1. Select the books relationship of the Library entity in the editor’s table style. Open the Data Model Inspector in the Utilities pane on the right to see the details of the relationship.
  2. In the Data Model Inspector, you can modify the relationship’s destination and inverse relationship. You can also modify the relationship’s type or cardinality. Core Data supports To-One and To-Many relationships. Set Type to To-Many.

Switch back to graph to see changes. The relationship from Library to Book now has two arrows, indicating that books is a to-many relationship.

MANY-TO-MANY RELATIONSHIPS <<—>>

There might be a real word scenario where book/books can belong to many libraries. To fulfill this relationship we need to turn the library relationship into a to-many relationship.

Select the library relationship of the Book entity in the editor’s table style and set Type to To-Many in the Data Model Inspector.

For the best naming convention practices update the name of the relationship to libraries so that it is easily understood that a book can belong to multiple libraries.

This is what the data model graph looks like after the changes. The relationship that links the Library and Book entities is now a many-to-many relationship.

Very important note

The recommended approach is to model relationships in both directions and specify the inverse relationships appropriately. Core Data uses this information to ensure the consistency of the object graph if a change is made.

Reference of apple documentation

You might get this warning if you set no inverse relationship in Xcode:

warning: Misconfigured Property: Person.address should have an inverse

Fix

Just add a inverse relationship from Address to Person and warning is gone.

Add relationship from Address to Person(Destination) like this :

And finally it should look like this :).

Let’s write some code to understand relationships:

Create a new project in Xcode. Choose single view from project template, give it name CoreDataRelationships andand include Core Data. Now click on CoreDataRelationships.xcdatamodeld. We will add some entities and relationships in Editor.

Write now your editor will blank looking like below image:

 

Click on Add Entity button and create entities. For example create two entities Person and Passport as below screen shot :

Click on + icon in attribute section to add some attributes for Person and Passport entity. Create firstName & lastName attributes of Person entity as per below image:

 

Similarly create passportId attribute as per below image:

One to one example

A person can only have one passport.So we will create a relationship from person to passport. Click on + icon under relationships . As soon as you will click on it a relationship will be created. See attached image:

Enter passport string in relationship.

Enter Passport in destination field.

Similarly click on Passport entity. click on + icon to create a relationship.

Enter person string in relationship

Enter Person in destination.

finally click on inverse and choose Person. Finally complete setup will look like this:

 

 

 

Build once to make sure every thing is perfect.

Core data automatically generates helper files for us at location

~/Library/Developer/Xcode/DerivedData

The complete path in my case is :

~/Library/Developer/Xcode/DerivedData/CoreDataRelationships-gmfbavojplsilicxammyddhvvgqy/Build/Intermediates.noindex/CoreDataRelationships.build/Debug-iphonesimulator/CoreDataRelationships.build/DerivedSources

This is the attached screen shot:

Let’s explore it further:

So, you can see number of autogenerated files for. Let’s see some important files:

Passport+CoreDataClass

The class is a model and is subclass of NSManagedObject. It follows naming convention EntityName+CoreDataClass. following naming convention here it is Passport+CoreDataClass.

Passport+CoreDataProperties.swift

See the magic, this extension automatically provides some helper methods for us. Example it provides us fetchRequest, and automatically created properties passportId & person. @NSManaged means we are telling compiler the value to these properties will be computed at runtime.

Similarly we have two more files for Person Person+CoreDataClass.swift & Person+CoreDataProperties.swift. Explanation remains same as above.

Let’s open Main.storyboard drag drop two UILabels, name them lblPassportdetails and lblVehicalDetails (will use in another example), create IBOutlets & make a setup like this:

 

 

Let’s copy and paste below code in ViewController file:

Now call oneToOneExample() from viewDidLoad() method like this:

Build and run your project, we should see out put like this:

One to many example <—>>

Best example for one to many relationship is – a person can have more than one vehicles. Let’s design this system.

Relationship between Person and Vehicals looks like this

 

Open ViewController file copy paste below code:

Complete code of ViewController class should look like this:

Final Output  😀

Source code is here.

DELETE RULES

Delete rules are one of the conveniences that make working with Core Data great. Every relationship has a delete rule. It defines what happens when the record that owns the relationship is deleted. Let me explain what that means.

Core Data supports four delete rules:

Cascade, Deny, Nullify, No Action.

Cascade

Cascade delete with one to one inverse

Delete the objects at the destination of the relationship when you delete the source.

For example, if you delete a department, fire all the employees in that department at the same time.

Lets See an example where we have a Cascade delete rule.

We have two entities “Person” and Address.

Person have the inverse relationship with Address. 

Address have the inverse relationship with Person. 

Delete rule is cascade for Address entity.

Delete rule is cascade for Person entity.

It is a inverse relationship, that is destination entity knows about the state of source. Here “Person” knows about “Address” and vice versa. If we delete person entity, then address should also be delete.

Lets see in the video example what’s going on:

video

Source Code

Cascade delete with one to one no inverse

Lets say there in unidirectional relationship from person to address but not vice versa. It means if we delete person entity, address entity still exist. Because person nows about address but address do not have inverse relationship back to person entity. “Thats why it is encouraged to use bidirectional relationship”

Source Code

Video

Deny

If there is at least one object at the relationship destination (employees), do not delete the source object (department).

For example, if you want to remove a department, you must ensure that all the employees in that department are first transferred elsewhere; otherwise, the department cannot be deleted.

Nullify

Remove the relationship between the objects, but do not delete either object.

This only makes sense if the department relationship for an employee is optional, or if you ensure that you set a new department for each of the employees before the next save operation. This is the default delete rule and the delete rule you will find yourself using most often.

No Action

Do nothing to the object at the destination of the relationship.

For example, if you delete a department, leave all the employees as they are, even if they still believe they belong to that department.

That’s it for now from basic fundamentals. Working on code examples now and will post them very soon.

Thanks posting soon next part 🙂 !! Here you go!!