What (if any) ACID guarantees can Core Data provide on iOS?

Question

I'm working on an app where I need to persist data in a reliable manner, i.e. updates need to be persisted all-or-nothing even in the face of application crashes and quits etc.

However I can't find much information on the level of resilience Core Data is able to support and from looking around it seems that Core Data corruption is a possibility. Is this correct or is Core Data able to provide the high and low level ACID properties needed to support reliable data storage?

Please be specific as to which APIs give these guarantees - for example is a save guaranteed to commit all updates or none, even if a crash occurs (possibly on another thread) during the save?

Answer 1

ACID only applies to databases and Core Data isn't a database API so the ACID standard doesn't really apply to Core Data. At best ACID applies only in the case of the use of a SQLite persistent store and does not apply to binary, xml, in-mmemory or custom atomic stores.

The NSManagedObjectContext do enforce the first three ACID components: Atomicity, Consistency and Isolation. You can in principle turn on SQLite's logging function and get Durability.

ACID was conceived as a theoretical standard for multiuser, big-iron databases. Atomicity, Consistency and Isolation are all intended to keep multiple simultaneous user transactions from corrupting the database by stepping on each other. Durability really applies only to a system that cannot be practically backed up otherwise.

Core Data, by contrast, is an API for implementing the model layer of Model-View-Controller design application. It's persistence functions are merely optional. It does not support multiple users but merely multiple subprocesses of the same app.

There is no system which can perfectly guarantee data integrity in the face of a hardware failure. At best you can guarantee that you can revert to an earlier version of the data but you cannot protect against hardware failure while you are making changes.

Having said all that, Core Data is very robust. I have seen a literal handful of cases of corrupt persistent stores and then usually only under extreme conditions. I don't think any other system currently available for desktop and mobile platforms is more reliable.

Update:

Please be specific as to which APIs give these guarantees - for example is a save guaranteed to commit all updates or none, even if a crash occurs (possibly on another thread) during the save?... The kinds of failures I am referring to are crashes within the app or quitting of the app - in this case it is desirable that only the last transaction gets affected (i.e. lost, at worst), but I don't see how to express this with Core Data

There are two areas of concern here, the operations of the persistent store writing to disk and the operations of the managed object context in maintaining object graph integrity and saving the graph.

For the SQLite store, SQLite itself is ACID compliant:

A transactional database is one in which all changes and queries appear to be Atomic, Consistent, Isolated, and Durable (ACID). SQLite implements serializable transactions that are atomic, consistent, isolated, and durable, even if the transaction is interrupted by a program crash, an operating system crash, or a power failure to the computer.

For the other stores, which are written out as unitary files, Core Data will use safe write methods that insure that an existing good file will not be overwritten by a corrupted file.

At the higher abstraction level of the object graph, the managed object context performs validations before writing to the store and will reject the entire write attempt if any validation errors occur.(Link Pending.) This behavior is necessitated by the object graph.

An object graph is a collection of related live objects in memory. Unlike a procedural database, where data is only encoded in fields, the relationships between the objects encodes vital data. Therefore, the entire graph must be validated in step and then saved in one step. (Of course, behind the scenes using an sqlite store, there will be procedural ACID compliant steps but validation of the object graph occurs before this level is reached.)

E.g. You have a data model to model/simulate a file system. It has two entities: Folder and File. Each File object has a required relationship with a single Folder object because each real-world file is always inside a folder. However, you insert a file object that has no folder. When the context validates the object graph for a save, it will reject the entire graph because the graph is nonsensical with a file object that is not inside a folder.