iphone - ¿Pueden los datos básicos manejar mis necesidades de migración de "sistema frente a datos de usuario"?

core-data data-migration

Question

La aplicación de mi iPhone tendrá datos de "sistema" de solo lectura Y datos de "usuario" de lectura / escritura (almacenados con Core Data o un DB de SQLite personalizado). Los datos del usuario pueden hacer referencia a los datos del sistema. Cuando se instala una nueva versión de la aplicación (por ejemplo, a través de iTunes):

• Los nuevos datos del sistema que vienen con la actualización deben sobrescribir / reemplazar los datos del sistema anterior
• Los datos del usuario se deben modificar para hacer referencia a los nuevos datos del sistema (cuando sea posible).

Pregunta: ¿Cómo se realiza este tipo de migración con Core Data? ¿Es factible?

Por ejemplo, digamos que mi aplicación es para administrar recetas.

• Cada versión de la aplicación vendrá con un conjunto predeterminado de recetas.
• El usuario no puede editar estas recetas "oficiales".
• Sin embargo, el desarrollador puede modificar (o eliminar) cualquier receta "oficial" en futuras versiones de la aplicación.
• Los usuarios pueden agregar notas / comentarios a las recetas "oficiales" (por ejemplo, "hornear durante 45 minutos en lugar de 30").

Cuando el usuario se actualiza a una nueva versión de la aplicación, queremos mantener los comentarios de los usuarios y tratar de volver a asociarlos con recetas coincidentes del nuevo conjunto "oficial" de recetas. ¿Es esto posible / factible con Core Data? ¿O quizás debería usar una solución simple de "base de datos" (por ejemplo, SQLite y operaciones tradicionales de creación / lectura / actualización / eliminación)?

¡Gracias!

Answer 1

Deberías tener dos tiendas persistentes. Una tienda de solo lectura que se encuentra en su paquete y una tienda de lectura / escritura que se encuentra en el directorio de documentos.

Puede agregar ambas tiendas a NSPersistentStoreCoordinator y acceder a ellas desde un NSManagedObjectContext .

Si ambas tiendas tienen la misma entidad, querrás llamar a -assignObject:toPersistentStore: para indicar a Core Data en qué tienda guardar la entidad. Si cada modelo subyacente tiene entidades diferentes, entonces esto no es necesario.

Además, puede "enlazar" notas a una receta de solo lectura asegurándose de que cada receta tenga un identificador único (que usted crea) y la nota almacena eso para que pueda usar una propiedad recuperada para recuperar la receta asociada y asociar notas.

ObjectID

Primero, no use el -objectID para enlazar entre tiendas. Puede cambiar y cambia durante la migración (y otras veces) lo que hará que su migración MUCHO más fea de lo necesario.

Migración

La migración es muy directa. Si necesita cambiar el modelo de datos de solo lectura, simplemente cámbielo e incluya la nueva versión con su aplicación.

Si necesita cambiar el modelo de lectura y escritura, cree un nuevo modelo, utilice la migración automática durante las pruebas y, cuando esté listo para enviar, escriba un NSMappingModel de la versión anterior a la nueva.

Debido a que las dos tiendas persistentes (y sus modelos asociados) no están vinculadas, existe muy poco riesgo con la migración. La única "captura" es que el código de plantilla para Core Data no podrá resolver automáticamente el modelo de origen para la migración. Para resolver este problema, debe intervenir un poco y ayudarlo:

1. NSPersistentStoreCoordinator su NSPersistentStoreCoordinator destino y observe si hay un error. Si obtiene un error de migración:
2. Encuentre los modelos fuente y cree una instancia de NSManagedObjectModel con todos los modelos fuente apropiados.
3. Crea una instancia de NSMigrationManager y dale los modelos de origen y destino
4. Llamar - migrateStoreFromURL: type: options: withMappingModel: toDestinationURL: destinationType: destinationOptions: error: para iniciar la migración
5. ¡Lucro!

Es un poco más trabajo manejar la migración de esta manera. Si sus dos modelos están muy separados, podría hacerlo un poco diferente, pero requerirá pruebas (como lo hacen todas las cosas):

1. Captura el error de migración
2. NSPersistentStoreCoordinator un nuevo NSPersistentStoreCoordinator solo con la tienda persistente (y el modelo) que necesita migrar.
3. Deja que ese emigre.
4. NSPersistentStoreCoordinator ese NSPersistentStoreCoordinator e intenta levantar tu NSPersistentStoreCoordinator principal nuevamente.