Switching Between XML and SQLite in Core Data

Of the four data storage formats which Core Data on OS X supports some developers may use two: XML and SQLite. XML can be great when you are developing your application and want to have a look at what Core Data is storing whilst SQLite is more memory friendly and is generally used in shipping applications (the XML format is easy to read in a text editor but more memory hungry because it loads all of the data into memory). Note: After initially publishing this post I received some feedback on Twitter about the perils of using an XML data store. This is covered in a section at the end of this post.

If the initial development was done using the XML store the developer will at some point throw away the existing test data and reconfigure the NSPersistentStoreCoordinator to use SQLite and then stick with that format. Whilst third-party tools exist which allow you to examine the data in the SQLite data store it easy to toggle between XML and SQLite using Core Data itself. This not only allows you to examine the data easily but it also means that when you transition from XML to SQLite you need not lose any data, possibly important if you have alpha or even beta testers using your application.

The conversion process is handled by the NSPersistentStoreCoordinator’s migratePersistentStore:toURL:options:withType:error: method. Essentially you need to:

1. Create a new NSPersistentStoreCoordinator.
2. Add the existing NSPersistentStore to it.
3. Call the migratePersistentStore:toURL:options:withType:error: method.

It’s the withType: parameter of the method which performs the actual conversion.

This is easier to follow in code so please have a look at the migrateData: method in the AppDelegate.m file in the sample project.

There are a few things to note about the sample project.

• At the top of the AppDelegate class the two configurations are defined. Comment out the one you don’t want to use. In the example XML is the initial store type.
• The AppDelegate class’s init method is used to call the migrateData method. This ensures that it is called before the Core Data stack is used and the persistent store coordinator created.
• When you replace one format with another the original data file is renamed with an ’ - Archive’ suffix. The segment of code which does this doesn’t do any error checking, you really should in your production code.
• The Core Data methods are taken from Marcus Zarra’s article about cleaning up the default Core Data project.
• All the code used in the example project is released into the public domain.

The Perils of XML

As mentioned above, some Twitter feedback pointed out the perils of using the XML format. Kevin Hoctor and Danny Greg of No Thirst Software, Matt Drance of Bookhouse and Drew McCormack of The Mental Faculty all mentioned issues which can occur when you switch from and XML-based store to a SQLite-based one. They are covered in Apple’s Persistent Store Features document. I confess to not having read this article for a couple of years so the gotchas had slipped from my mind some time ago.

Their advice is simply to avoid using the XML store type and to use third-party applications such as Core Data Editor and Base to examine your data. I like Core Data Editor but don’t find it particularly intuitive to configure and have had discussions with people who could never got it to work for them. Base is currently an unknown quantity for me but I will be checking it out.

However, I have had (and expect to have in the future) cases where clients have asked to an XML-based data file to allow them to easily examine the data and having the ability to switch over to the XML format, even if it is only a temporary measure, may be useful. As for whether you should use it during your development cycle at all, the perceived wisdom is not to .