iOS CoreData - il des inconvénients à l'activation de sqlite WAL / Write-Ahead Logging

Lors de la WWDC 2013 session '207: Quoi de neuf dans la Base de Données', ils mentionnent que vous pouvez activer SQLite WAL en passant, un dictionnaire lors de l'ajout d'un magasin persistant:

@{ NSSQLitePragmasOption: @"journal_mode = WAL" }

(qui est disponible sur iOS4+ et sera la valeur par défaut pour les futures versions iOS).

Je me demande si ce serait généralement une bonne chose à activer dans mon application pour les précédentes versions iOS trop.

J'ai consulté le SQLite page sur écrire à l'avance de journalisation et les inconvénients qu'ils mentionnent, la plupart d'entre eux ne semblent pas s'appliquer à iOS, à l'exception de:

  • WAL peut-être très légèrement plus lent (peut-être 1% ou 2% plus lent) que l'
    traditionnelles de restauration-journal de l'approche dans les applications que dans la plupart des cas
    lit et rarement écrire.

à peu près tous les avantages de le faire sonner comme ils vont probablement être un avantage sur iOS:

  • WAL est nettement plus rapide dans la plupart des scénarios.
  • WAL fournit plus de la simultanéité comme les lecteurs de ne pas bloquer les écrivains et un écrivain ne bloque pas les lecteurs. La lecture et l'écriture peut être réalisée en même temps.
  • Disk I/O operations a tendance à être plus séquentielle à l'aide de WAL.
  • WAL utilise beaucoup moins de fsync() exploitation et est donc moins vulnérables à des problèmes sur les systèmes où la fsync() de l'appel système est cassé.

Je suis considère que (peut-être sujet à faire quelques vérifications sur mon appli pour assurez-vous de ne pas ralentir les choses) que ce serait une bonne chose pour l'activer, mais est-il un inconvénient que je devrait voir le ou les problèmes connus?

InformationsquelleAutor JosephH | 2013-07-05
  1. 18

    http://pablin.org/2013/05/24/problems-with-core-data-migration-manager-and-journal-mode-wal/ suggère que leurs problèmes avec les migrations, en particulier:

    Lorsque vous utilisez un Gestionnaire de Migration de Base de Données permettra de créer une nouvelle base de données
    pour vous, et de commencer à copier les entités, un par un à partir de l'ancienne DB à
    le nouveau.

    Que nous utilisons journal_mode = WAL, il y a un fichier supplémentaire en plus de
    DB.sqlite appelée DB.sqlite-wal.

    De ce que je peux dire, le problème semble être que la Base de Données crée un
    temporaire DB, inserts de tout, et quand il le renomme l'
    nom d'origine, le -wal fichier est conservé comme un vestige de l'ancien
    version. Le problème est que vous vous retrouvez avec un incohérent DB.

    (également mentionnée sur https://github.com/magicalpanda/MagicalRecord/issues/490 - ce qui suggère que si vous utilisez magique enregistrement puis c'est déjà la valeur par défaut WAL )

    • Il est à noter que cela n'arrive que dans les "avancées" des migrations, lorsque vous avez besoin d'un Gestionnaire de Migration. Moins radical migrations (comme l'ajout ou le changement de nom d'une colonne) fonctionnent très bien, qu'ils sont effectués sur la même base de données et non pas une copie.
    • c'est bon à savoir, merci pour les précisions!
    • Ne pourrait-on pas désactiver temporairement WAL, la suppression de la revue (-wal fichier), puis effectuez la migration ...?
    • La Migration de la base de données se produit généralement lors du démarrage d'une application. N'est-ce pas dire que le point de contrôle doit déjà avoir exécuté au cours de la dernière demande de fermer?
    • Le problème est juste au cours d'une avancée de la migration, où coredata ne parvient pas à renommer un fichier correctement. La solution mentionnée dans le lié billet de blog, en précisant journal_mode = SUPPRIMER lorsque l'application détecte une migration qui doit arriver, évite que la fichier existant au moment de la migration se produit.
    InformationsquelleAutor JosephH
  2. 2

    Concernant le bug qui se produit avec les non-léger migrations qui comportent des sous-classement NSMigrationManager, que j'ai re-signalé à Apple que le Bug 16038419.

    J'ai aussi fait un autre, méthode-swizzling solution de contournement patchs le bug dans le cas où vous toujours souhaitez utiliser l'héritage de suppression/restauration de la journalisation. Comme je le comprends, Pablin fixer est pour les cas où vous souhaitez utiliser WAL sauf pendant les migrations. Aussi, vous pouvez voir que le bug se produire dans cette vidéo.

    • Génial, merci. D'intérêt, dans ce cas, voulez-vous de toujours éviter de WAL?
    • Cas 1: Mac OS X Base de Données d'une app à l'aide de packages de fichier. Le fichier sqlite est le fichier de document. Les utilisateurs gratter la tête quand ils voient -shm et -wal fichiers adjacents à leurs documents dans le Finder. Ils peuvent penser que ce sont des cochonneries et soit ordures, ou de les ignorer lorsque le déplacement ou la copie de fichier du document. Résultat: la perte de données. Cas 2: "WAL journal_mode n'est pas, cependant, recommandé pour la lecture seule des fichiers de base de données, ou pour les fichiers qui doivent interagir avec iOS 4 ou une version antérieure." C'est à partir de: developer.apple.com/library/ios/releasenotes/DataManagement/...
    InformationsquelleAutor Jerry Krinock