Daniel Tull: Blog

Not a Core Data error

Friday, 20 November 2015

SQLite error code:522, 'not an error’

This morning I came across the above, before seeing the app crash. Clearly not an error!

In Issues I make use of Core Data and one thing I decided early on was to use its store as a cache only: All data in the Core Data store can be fetched again from the server. There were a couple of reasons for this choice:

  • It keeps me flexible to model changes, without the overhead of migration.
  • I could store user-created entities such as favourites, draft issues and draft comments in files NSCoding, which in turn allowed me to easily adopt CloudKit.

When a model change happens, I delete the store at the URL I gave and recreate a new one in its place.

The problem above occurred for me because Core Data creates journaling files alongside the file I specify. When I delete the store, I don’t touch these files, mainly because there’s not really a way to know about them – they have the same filename prefix with -wal or -shm appended, so I could delete all the files with the same filename prefix.

An easier solution I saw was to create a directory at the URL and make the actual store inside that directory. This way, when I need to delete the store, I can remove the folder safely knowing that all the journaling files will be removed as well.

Update 26th November 2015

Pete Callaway has pointed out to me that the following method was added to NSPersistentStoreCoordinator in iOS 9 that deletes a store and its associated files.

destroyPersistentStoreAtURL:withType:options:error:

This should negate the need to try to guess what extra files Core Data or SQL might create now or in the future.

It was also mentioned at WWDC this year.