iOS CoreData - 启用sqlite WAL / Write-Ahead Logging有任何缺点

Question

在WWDC 2013会议'207：Core Data中的新功能'中，他们提到您可以通过在添加持久存储时传递选项字典来启用SQLite WAL：

@{ NSSQLitePragmasOption: @"journal_mode = WAL" }

（可在iOS4 +上使用，将成为未来iOS版本的默认设置）。

我想知道在我的应用程序中为早期iOS版本启用这通常是一件好事。

我已经咨询了SQLite page about write ahead logging以及他们提到的缺点，其中大多数似乎不适用于iOS：

• WAL可能会慢得多（可能慢1％或2％） 大多数应用程序中的传统rollback-journal方法 读，很少写。

几乎所有优势听起来都像是iOS上的好处：

• 在大多数情况下，WAL明显更快。
• WAL提供更多的并发性，因为读者不会阻止编写者，而编写者不会阻止读者。阅读和写作可以同时进行。
• 使用WAL，磁盘I / O操作往往更顺序。
• WAL使用更少的fsync（）操作，因此在fsync（）系统调用被破坏的系统上不易受到问题的影响。

我很想（可能需要对我的应用程序进行一些检查，以确保它不会减慢速度），这对于启用是件好事，但是我应该注意或者任何已知的任何缺点问题

Answer 1

http://pablin.org/2013/05/24/problems-with-core-data-migration-manager-and-journal-mode-wal/表明他们可能是迁移问题，尤其是：

  

使用迁移管理器时，Core Data将创建一个新数据库   为你，并开始从旧数据库逐个复制实体   新的。

     

由于我们使用的是journal_mode = WAL，还有一个额外的文件   DB.sqlite名为DB.sqlite-wal。

     

据我所知，问题似乎是Core Data创建了一个   临时DB，在那里插入所有内容，以及何时将其重命名为   原始名称，-wal文件保留为旧文件的剩余部分   版。问题是你最终得到了一个不一致的数据库。

（也在https://github.com/magicalpanda/MagicalRecord/issues/490上提到 - 这表明如果你使用魔法记录，那么它已经默认为WAL）

Answer 2

关于涉及子类化NSMigrationManager的非轻量级迁移所发生的错误，我已将其作为错误16038419重新报告给Apple。

我还做了一个不同的method-swizzling workaround，在您总是想要使用旧版删除/回滚日记功能的情况下修补该错误。据我了解，Pablin's fix适用于您希望在迁移期间使用WAL 除之外的情况。此外，您可以在this video中看到错误。