Core Data Programming Guide Notes -- Part 4

This is the notes of Core Data Programing Guide from reading Apple's document

reference: http://developer.apple.com/library/ios/#DOCUMENTATION/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html#//apple_ref/doc/uid/TP30001200-SW1

Using Persistent Stores
 Creating and Accessing a Store

 Access to stores is mediated by an instance of NSPersistentStoreCoordinator. You should not need to directly access a file containing a store. From a persistent store coordinator, you can retrieve an object that represents a particular store on disk. Core Data provides an NSPersistentStore class to represent persistent stores.

 

To retrieve a store object from a coordinator, you use the method persistentStoreForURL:. You can use a store to restrict a fetch request to a specific store, as shown in the following code fragment:

Core Data and Cocoa Bindings

Note that Cocoa bindings are not available on iOS. 

Change Management

Conflict Detection and Optimistic Locking 

When Core Data fetches an object from a persistent store, it takes a snapshot of its state. A snapshot is a dictionary of an object’s persistent properties—typically all its attributes and the global IDs of any objects to which it has a to-one relationship. 

If the values are the same, then the store has not been changed since the object was fetched, so the save proceeds normally. As part of the save operation, the snapshots' values are updated to match the saved data.

If the values differ, then the store has been changed since the object was fetched or last saved; this represents an optimistic locking failure. 

Conflict Resolution

You can get an optimistic locking failure if more than one persistence stack references the same external data store (whether you have multiple persistence stacks in a single application or you have multiple applications). 

The default behavior is defined by the NSErrorMergePolicy. This policy causes a save to fail if there are any merge conflicts. 

In the case of failure, the save method returns with an error with a userInfo dictionary that contains the key @"conflictList"; 

The NSErrorMergePolicy is the only policy that generates an error. Other policies—NSMergeByPropertyStoreTrumpMergePolicy, NSMergeByPropertyObjectTrumpMergePolicy, and NSOverwriteMergePolicy—allow the save to proceed by merging the state of the edited objects with the state of the objects in the store in different ways. The NSRollbackMergePolicy discards in-memory state changes for objects in conflict and uses the persistent store’s version of the objects’ state.

Snapshot Management
An application that fetches hundreds of rows of data can build up a large cache of snapshots. 

Responsibility for cleaning up snapshots rests with a mechanism called snapshot reference counting. 

Communicating Changes Between Contexts
The following three strategies are presented in order of increasing complexity.

1.The simplest case is when the object itself has not changed in moc2 and you do not have to worry about undo; in this situation, you can just delete the object. The next time moc2 saves, the framework will notice that you are trying to re-delete an object, ignore the optimistic locking warning, and continue without error. 

2.If you do not care about the contents of moc2, you can simply reset it (using reset) and refetch any data you need after the reset. This will reset the undo stack as well, and the deleted object is now gone. The only issue here is determining what data to refetch. You can do this by, before you reset, collecting the IDs (objectID) of the managed objects you still need and using those to reload once the reset has happened (you must exclude the deleted IDs, and it is best to create fetch requests with IN predicates to avoid problems will not being able to fulfill faults for deleted IDs). 

3. If the object has changed in moc2, but you do not care about undo, your strategy depends on what it means for the semantics of your application. If the object that was deleted in moc1 has changes in moc2, should it be deleted from moc2 as well? Or should it be resurrected and the changes saved? What happens if the original deletion triggered a cascade delete for objects that have not been faulted into moc2? What if the object was deleted as part of a cascade delete?

There are two workable options (a third, unsatisfactory option is described later):

1. The simplest strategy is to just discard the changes by deleting the object.
   

Alternatively, if the object is standalone, you can set the merge policy on the context to NSMergePolicyOverwrite. This will cause the changes in the second context to overwrite the delete in the database.

Note that this will cause all changes in moc2 to overwrite any changes made in moc1. 

Persistent Store Features
Store Types and Behaviors
Core Data provides three sorts of disk-based persistent store—XML, atomic, and SQLite—and an in-memory store. 

iOS: The XML store is not available on iOS. 

  

File Size May Not Reduce After Deleting a Record