The Problem

Early in development, the data model model changes often, and errors are inevitable. Forget to make a new attribute optional, and the code blows up while saving the context. Because I move pretty fast and change things often, this kind of stuff happens to me all the time. Core Data provides me this error message quite often:

Domain=NSCocoaErrorDomain Code=1560 UserInfo=0x14f5480 "Operation could not be completed. (Cocoa error 1560.)"

For the developer inexperienced with Core Data, this is a very disheartening message. It does not give us any indication of what went wrong or how we should attempt to fix the problem.

The Solution

It turns out that, if there is more than one error, Core Data puts an array of NSError objects in the userInfo dictionary with the key NSDetailedErrorsKey. This is not obvious, and it drove me crazy for a while until I turned to Stack Overflow where someone else had already asked my question. There, someone named Charles provided this solution with code to get at the "real" error. Overjoyed, I turned the code into a macro, and I use it exclusively to save a context during development. Here is the macro:

#define FT_SAVE_MOC(_ft_moc) \
do { \
  NSError* _ft_save_error; \
  if(![_ft_moc save:&_ft_save_error]) { \
    NSLog(@"Failed to save to data store: %@", [_ft_save_error localizedDescription]); \
    NSArray* _ft_detailedErrors = [[_ft_save_error userInfo] objectForKey:NSDetailedErrorsKey]; \
    if(_ft_detailedErrors != nil && [_ft_detailedErrors count] > 0) { \
      for(NSError* _ft_detailedError in _ft_detailedErrors) { \
        NSLog(@"DetailedError: %@", [_ft_detailedError userInfo]); \
      } \
    } \
    else { \
      NSLog(@"%@", [_ft_save_error userInfo]); \
    } \
  } \
} while(0);

Now, whenever I need to save the context, I can do it safely and comfortably like so:

FT_SAVE_MOC([self managedObjectContext])

This macro only prints the error messages, but all I want during development is error messages in the console. This code can easily be moved to a function or method to do more robust error handling in a production scenario, but that would fill an entire post on its own.

The Problem

Core Data allows you to choose from multiple backend storage methods, and, other than having to choose a type, the data store is completely transparent. The recommended store on the iPhone is sqlite, and not only is it fast, but the schema generated by Core Data is fairly readable. Being able to poke around in the sqlite file was an immeasurable help while I was learning Core Data. The biggest problem is finding the sqlite database file. Every time you build and run your app in the simulator, the application directory is renamed with a new GUID which makes it really hard to find:

Can you find your app?

The Solution

Thankfully, OS X has the full compliment of unix command line tools. Wrap the proper commands in a Makefile, and you have some instant command line Core Data database management tools. Unix to the rescue! Here are the four make targets that I use the most:

SQLITE_DB_FILE=AppData.sqlite
SIMULATOR_HOME=$(HOME)/Library/Application\ Support/iPhone\ Simulator

dbshell:
      find $(SIMULATOR_HOME) -name "$(SQLITE_DB_FILE)" -exec sqlite3 {} ';'

killdb:
      find $(SIMULATOR_HOME) -name "$(SQLITE_DB_FILE)" -exec rm {} ';'

dbschema:
      find $(SIMULATOR_HOME) -name "$(SQLITE_DB_FILE)" -exec sqlite3 {} .schema ';'

dbdump:
      find $(SIMULATOR_HOME) -name "$(SQLITE_DB_FILE)" -exec sqlite3 {} .dump ';'

The target names should make their use self explanatory, but I’ll summarize them:

dbshell

Open up the sqlite command line shell with the Core Data database selected.

killdb

Delete the database file. This is useful if you’re making big changes to the schema and you would rather delete the whole database and start over rather than migrating the schema.

dbschema

Dumps the CREATE statements required to recreate the schema. This is useful to see how Core Data persists your object graph.

dbdump

Dumps the schema as CREATE statements and all of the data as INSERT statements.

There is nothing magical or difficult about these, but I have found them to be very useful while developing my data model.