ios - tutorial - qgis introduccion

iOS CoreData: ¿existen desventajas para habilitar el registro WAL/Write-Ahead de sqlite

Question

En la sesión de la WWDC 2013 ''207: Novedades de los datos básicos'', mencionan que puede habilitar SQLite WAL pasando un diccionario de opciones al agregar un almacén persistente:

@{ NSSQLitePragmasOption: @"journal_mode = WAL" }

(que está disponible en iOS4 + y será el predeterminado para futuras versiones de iOS).

Me pregunto si esto también sería bueno habilitarlo en mi aplicación para versiones anteriores de iOS también.

He consultado la página de SQLite sobre el registro de escritura anticipada y las desventajas que mencionan, la mayoría de ellos parece que no se aplican a iOS aparte de:

• WAL podría ser un poco más lento (tal vez 1% o 2% más lento) que el enfoque tradicional de rollback-journal en aplicaciones que en su mayoría lee y rara vez escribe.

casi todas las ventajas parecen ser un beneficio para iOS:

• WAL es significativamente más rápido en la mayoría de los escenarios.
• WAL proporciona más concurrencia ya que los lectores no bloquean a los escritores y un escritor no bloquea a los lectores. La lectura y la escritura pueden proceder al mismo tiempo.
• Las operaciones de E / S de disco tienden a ser más secuenciales utilizando WAL.
• WAL utiliza muchas menos operaciones fsync () y, por lo tanto, es menos vulnerable a los problemas en los sistemas en los que se interrumpe la llamada al sistema fsync ().

Estoy asumiendo (quizás sujeto a hacer algunas comprobaciones en mi aplicación para asegurarme de que no ralentice las cosas) que esto sería algo bueno para habilitar, pero ¿hay algún inconveniente que deba tener en cuenta o algún problema conocido?

Answer 1

Con respecto al error que se produce con las migraciones no ligeras que involucran la subclasificación de NSMigrationManager, que he reportado a Apple como Bug 16038419.

También he creado una solución alternativa diferente que mezcla los métodos y corrige el error en los casos en los que siempre desea utilizar el diario de borrado / retroceso heredado. Como lo entiendo, http://pablin.org/2013/05/24/problems-with-core-data-migration-manager-and-journal-mode-wal/ es para los casos en que desea utilizar WAL, excepto durante las migraciones. Además, puedes ver que el error ocurre en este video .

Answer 2

http://pablin.org/2013/05/24/problems-with-core-data-migration-manager-and-journal-mode-wal/ sugiere que podrían ser problemas con las migraciones, en particular:

Cuando usa un Administrador de Migración, Core Data creará una nueva base de datos y comenzará a copiar las entidades una por una desde la base de datos antigua a la nueva.

Como estamos usando journal_mode = WAL, hay un archivo adicional además de DB.sqlite llamado DB.sqlite-wal.

Por lo que puedo decir, el problema parece ser que Core Data crea una base de datos temporal, inserta todo lo que hay allí, y cuando se le cambia el nombre al nombre original, el archivo -wal se mantiene como un resto de la versión anterior. El problema es que terminas con una base de datos inconsistente.

(También se menciona en https://github.com/magicalpanda/MagicalRecord/issues/490 , lo que sugiere que si usa el registro mágico, entonces ya está predeterminado para WAL)