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.
