iOS CoreData - are there any disadvantages to enabling sqlite WAL / Write-Ahead Logging

Question

At the WWDC 2013 session \'207: What\'s New in Core Data\', they mention that you can enable SQLite WAL by passing an options dictionary when adding a persistent store:

Answer 1

Regarding the bug that occurs with non-lightweight migrations that involve subclassing NSMigrationManager, which I've re-reported to Apple as Bug 16038419.

I've also made a different, method-swizzling workaround which patches the bug in cases where you always want to use legacy delete/rollback journaling. As I understand it, Pablin's fix is for cases when you want to use WAL except during migrations. Also, you can see that bug occur in this video.

Answer 2

http://pablin.org/2013/05/24/problems-with-core-data-migration-manager-and-journal-mode-wal/ suggests that their could be issues with migrations, in particular:

When you use a Migration Manager, Core Data will create a new database for you, and start copying the entities one by one from the old DB to the new one.

As we are using journal_mode = WAL, there’s an additional file besides DB.sqlite called DB.sqlite-wal.

From what I can tell, the problem seems to be that Core Data creates a temporary DB, inserts everything there, and when it renames it to the original name, the -wal file is kept as a leftover from the old version. The problem is that you end up with an inconsistent DB.

(also mentioned on https://github.com/magicalpanda/MagicalRecord/issues/490 - which suggests that if you use magical record then it is already defaulting to WAL )