Interview Questions And Answers – Core Data

  1. What is object graph in core data?
  2. What is core data?
  3. What is data persistance?
  4. What is core data stack?
  5. Give a example of data model?
  6. What are relationships in core data?
  7. What is abstract entity in core data?
  8. How to achieve Inheritance in core data entities?
  9. What is mainConcurrencyType?
  10. What is privateConcurrencyType?
  11. What is managed object context?
  12. How to create managed Object Context
  13. How to perform background task in core data
  14. Can we have more than one MOC
  15. Will you ever pass managedObject from one context to another context
  16. How to pass one managedObject from one context to other context
  17. What do you mean by thread safe
  18. What are different ways of creating private context
  19. How to write code for perform some long running task in background in core data
  20. What are core data delete rules
  21. What is NSAsynchronousFetchRequest
  22. How to set up NSAsynchronousFetchRequest
  23. How we can do multithreading with core data?
  24. How to transfer manage object from one thread to another thread?
  25. what is CoreData and what do we use it for
  26. is CoreData == sqlite or some wrapper?
  27. what types of stores does core data support
  28. What is the minimum necessary classes and relationship between them?
  29. Can the NSPersistentStoreCoordinator have more persistent stores?
  30. What is an NSManagedObjectId
  31. What is lazy initialization, how does this relate to core data, situations when this can be handy
  32. How to read only a few attributes of an entity
  33. What is a fetchedresultcontroller
  34. How to synchronize contexts
  35. How could one simulate an NSManagedObject (dynamic properties)
  36. What is relation
  37. what is insert command
  38. what is update command
  39. what is delete command
  40. persistant vs transient
  41. set up core data stack in iOS 9
  42. 5-6 points core data vs sqlite
  43. what is NSFetchResultController, will it block main UI
  44. When to do core data light weight migration all scenarios

Please support us by comment, like and share our facebook page.

Answers:

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.

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. Core Data’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)

Persistance Data

Save data in hard disk, so that it is available in multiple launched/ save data permanently.

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)

NSManagedObjectModel

  • 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.
  • 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.

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.

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.

Please support us by comment, like and share our facebook page.

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 :).

Abstract Entities

Specify that an entity is abstract if you will not create any instances of that entity. You typically make an entity abstract if you have a number of entities that all represent specializations of (inherit from) a common entity that should not itself be instantiated. For example, in the Employee entity you could define Person as an abstract entity and specify that only concrete subentities (Employee and Customer) can be instantiated. By marking an entity as abstract in the Entity pane of the Data Model inspector, you are informing Core Data that it will never be instantiated directly.

An Entity can be abstract, in which case it is never directly attached to a managed object.

An abstract object (in programming) or entity (in Core Data) is an object or entity that is never instantiated.

Entity Inheritance

Entity inheritance works in a similar way to class inheritance; and is useful for the same reasons. If you have a number of entities that are similar, you can factor the common properties into a superentity, also known as a parent entity. Rather than specifying the same properties in several entities, you can define them in one entity, and the subentities inherit them. For example, you might define a Person entity with attributes firstName and lastName, and subentities Employee and Customer, which inherit those attributes. An example of this layout is shown in Figure 2-3. Display the layout diagram by clicking the Editor Style buttons in the lower-right corner.

In many cases, you also implement a custom class to correspond to the entity from which classes representing the subentities also inherit. Rather than implementing business logic common to all the entities several times over, you implement them in one place and they are inherited by the subclasses.