CoreData Day-2 :: CoreData Components ?


1.NSIncrementalStore: NSIncrementalStore is an abstract superclass defining the API through which Core Data communicates with a store. This interface is designed to allow you to create persistent stores which load and save data incrementally, allowing for the management of large and/or shared datasets

2. NSIncrementalStoreNode : NSIncrementalStoreNode is a concrete class to represent basic nodes in a Core Data incremental store.

A node represents a single record in a persistent store.

You can subclass NSIncrementalStoreNode to provide custom behavior.

3. NSManagedObjectModel : The managed object model is the data model of the 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 NSManagedObjectModel object knows about the data model by loading one or more data model files during its initialization. We’ll take a look at how this works in a few moments.

– (NSManagedObjectModel *)managedObjectModel


    if (_managedObjectModel != nil) {

        return _managedObjectModel;


    NSURL *modelURL = [[NSBundle mainBundle] URLForResource:@”Core_Data” withExtension:@”momd”];

    _managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];

    return _managedObjectModel;


Delete Rule in NSManagedObjectModel

The Delete Rule menu has four options, No ActionNullifyCascade, and Deny.

No Action

If you select No Action, Core Data doesn’t update or notify the source record of the relationship. This means that the source record of the relationship still thinks it has a relationship with the record that was deleted. Note that this is rarely what you want.


This option sets the destination of the relationship to null when the destination record is deleted. This is the default delete rule of a relationship.


If the relationship from Person to Address is set to Cascade, deleting a person record will also delete any address records that are associated with the person record. This is useful, for example, if a relationship is required and the record cannot or shouldn’t exist without the relationship. A user, for example, shouldn’t exist if it’s not associated with an account.


In a sense, Deny is the inverse of Cascade. For example, if we have an Accountentity that has a to-many relationship with a User entity with its delete rule set to Deny, an account record can only be deleted if it has no user records associated with it. This ensures that no user records exist without an account record. The result is similar to the Cascade delete rule, but the implementation differs.

4. NSPersistentStoreCoordinator : As its name indicates, the NSPersistentStoreCoordinator object persists data to disk and ensures the persistent store(s) and the data model are compatible. It mediates between the persistent store(s) and the managed object context(s) and also takes care of loading and caching data. That’s right. Core Data has caching built in.

The persistent store coordinator is the conductor of the Core Data orchestra. Despite its important role in the Core Data stack, we rarely interact with it directly.

– (NSPersistentStoreCoordinator *)persistentStoreCoordinator


    if (_persistentStoreCoordinator != nil) {

        return _persistentStoreCoordinator;


    NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:@”Core_Data.sqlite”];

    NSError *error = nil;

    _persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];

    if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:nil error:&error]) {


         Replace this implementation with code to handle the error appropriately.

         abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.

         Typical reasons for an error here include:

         * The persistent store is not accessible;

         * The schema for the persistent store is incompatible with current managed object model.

         Check the error message to determine what the actual problem was.

         If the persistent store is not accessible, there is typically something wrong with the file path. Often, a file URL is pointing into the application’s resources directory instead of a writeable directory.

         If you encounter schema incompatibility errors during development, you can reduce their frequency by:

         * Simply deleting the existing store:

         [[NSFileManager defaultManager] removeItemAtURL:storeURL error:nil]

         * Performing automatic lightweight migration by passing the following dictionary as the options parameter:

         @{NSMigratePersistentStoresAutomaticallyOption:@YES, NSInferMappingModelAutomaticallyOption:@YES}

         Lightweight migration will only work for a limited set of schema changes; consult “Core Data Model Versioning and Data Migration Programming Guide” for details.


        NSLog(@”Unresolved error %@, %@”, error, [error userInfo]);



    return _persistentStoreCoordinator;


5.NSManagedObjectContext : The NSManagedObjectContext object manages a collection of model objects, instances of the NSManagedObject class. It’s perfectly possible to have multiple managed object contexts. Each managed object context is backed by a persistent store coordinator.

You can see a managed object context as a workbench on which you work with your model objects. You load them, you manipulate them, and save them on that workbench. Loading and saving are mediated by the persistent store coordinator. You can have multiple workbenches, which is useful if your application is multithreaded, for example.

While a managed object model and persistent store coordinator can be shared across threads, managed object contexts should never be accessed from a thread different than the one they were created on. We’ll discuss multithreading in more detail later in this series.

– (NSManagedObjectContext *)managedObjectContext


    if (_managedObjectContext != nil) {

        return _managedObjectContext;


    NSPersistentStoreCoordinator *coordinator = [self persistentStoreCoordinator];

    if (coordinator != nil) {

        _managedObjectContext = [[NSManagedObjectContext alloc] init];

        [_managedObjectContext setPersistentStoreCoordinator:coordinator];


    return _managedObjectContext;



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at

Up ↑

%d bloggers like this: