ACID 仅适用于数据库,Core Data 不是数据库 API,因此 ACID 标准并不真正适用于 Core Data。充其量 ACID 仅适用于使用 SQLite 持久存储的情况,不适用于二进制、xml、in-mmemory 或自定义原子存储。
NSManagedObjectContext 确实强制执行前三个 ACID 组件:原子性、一致性和隔离性。您原则上可以打开 SQLite 的日志记录功能并获得 Durability。
ACID 被认为是多用户大型数据库的理论标准。原子性、一致性和隔离性都是为了防止多个同时发生的用户事务相互影响而破坏数据库。持久性实际上只适用于无法实际备份的系统。
相比之下,Core Data 是一个 API,用于实现 Model-View-Controller 设计应用程序的模型层。它的持久性功能只是可选的。它不支持多个用户,仅支持同一应用程序的多个子进程。
没有任何系统可以在硬件故障时完美保证数据的完整性。充其量您可以保证您可以恢复到数据的早期版本,但您无法在进行更改时防止硬件故障。
话虽如此,Core Data 还是非常健壮的。我已经看到了一些损坏持久存储的案例,而且通常只在极端条件下。我不认为目前可用于桌面和移动平台的任何其他系统更可靠。
更新:
请具体说明哪些 API
提供这些保证 - 例如
一个保存保证提交所有
更新或无,即使崩溃
发生(可能在另一个线程上)
在保存期间?...的种类
我指的失败是崩溃
在应用内或退出应用
- 在这种情况下,最好只获得最后一个交易
受影响(即失去,最坏的情况),但我
不知道如何表达
核心数据
这里有两个方面需要关注,持久存储写入磁盘的操作和托管对象上下文在维护对象图完整性和保存图方面的操作。
对于 SQLite 存储,SQLite itself is ACID compliant:
事务数据库是其中之一
所有更改和查询都会出现
是原子的,一致的,孤立的,
和耐用(酸)。 SQLite 实现
可序列化的事务是
原子的、一致的、孤立的和
持久的,即使事务是
因程序崩溃而中断,
操作系统崩溃,或电源
电脑故障。
对于作为单一文件写出的其他存储,Core Data 将使用safe write methods,以确保现有的好文件不会被损坏的文件覆盖。
在对象图的更高抽象级别,托管对象上下文在写入存储之前执行验证,如果发生任何验证错误,将拒绝整个写入尝试。(链接挂起。)对象图需要此行为.
对象图是内存中相关活动对象的集合。与仅在字段中编码数据的程序数据库不同,对象之间的关系对重要数据进行编码。因此,必须一步一步验证整个图,然后一步保存。 (当然,在使用 sqlite 存储的幕后,会有符合 ACID 的程序步骤,但对象图的验证会在达到此级别之前进行。)
例如您有一个数据模型来建模/模拟文件系统。它有两个实体:Folder 和 File。每个File 对象都与单个Folder 对象具有必需的关系,因为每个真实世界的文件总是在一个文件夹中。但是,您插入一个没有文件夹的文件对象。当上下文验证对象图以进行保存时,它将拒绝整个图,因为该图对于不在文件夹内的文件对象是无意义的。