Migración de salas de base de datos en Android. Introducción Pavel Parrado Marín | Octubre de 2020

Dado que los datos persisten en las aplicaciones de Android, a veces necesitamos cambiar la estructura actual de la base de datos. La capacidad de realizar esta operación no es suficiente para simplemente cambiar las propiedades de un objeto DAO. Se requerirá la migración para retener los datos del usuario después de la actualización.

En este artículo se deben considerar varios conceptos:

Habitación, habitación – una biblioteca de persistencia que proporciona una capa de abstracción sobre SQLite que permite un acceso a la base de datos más robusto utilizando todo el poder de SQLite.

Objetos de acceso a datos (DAO): clases principales donde define las interacciones de su base de datos. Pueden incluir una variedad de métodos de consulta.

En este artículo, veremos algunas instancias diferentes de cambios en la base de datos y migraciones relacionadas para garantizar una transición sin problemas entre las versiones de Room DB:

  • Agregar un nuevo atributo
  • Cambiar el nombre del atributo
  • Cambiar el tipo de atributo a Nullable
  • Eliminar atributo
  • Agregue una nueva entidad a la sala de base de datos y use su PrimaryKey como ForeignKey

Se creará una entidad UserAccount para demostrar todos los casos de migración:

porFAl crear migraciones específicas, usaremos el contenido del archivo generado por Room Room. Una vez que eres construir su proyecto con Room estará disponible. Su nombre será el mismo que el de su clase DB, pero con _Impl sufijo.

Necesitaremos agregar un campo para comenzar la migración asignaturas a Room DB Builder, como se muestra a continuación:

Agregar un nuevo atributo

UserAccount tendrá apodo atributo ahora:

En tal caso, la migración:

Los parámetros del edificio son las versiones antigua y nueva de Room Room.

Cambiar el nombre del atributo

Atributo apodo será cambiado a Nombre de usuario en Cuenta de usuario:

Y las siguientes migraciones:

Tenemos 4 sentencias SQL en la migración. El primer comando que se puede obtener del archivo generado, que proporcionará la creación de una TABLA con todas las columnas. Luego cambiamos su nombre a temporal, copiamos el campo de la TABLA original, borramos el existente y cambiamos el nombre del temporal al original.

Cambiar el tipo de atributo a Nullable

Para esta migración Nombre de usuario el campo se cambiará a opcional:

Veamos qué se necesita para esta migración:

Para cambiar una columna a Nullable, necesitamos proporcionar cuatro declaraciones que solo cambian Nombre de usuario entrar a TEXTO sin NO CERO.

Eliminar el atributo

En esta parte tiramos Nombre de usuario campo de Cuenta de usuario:

Y la migración:

Como podemos ver, la TABLA generada automáticamente no contiene Nombre de usuario ya. Entonces haremos el mismo proceso y copiaremos solo los campos necesarios de la TABLA anterior. Entonces caemos Cuenta de usuario y cambie el nombre del temporal.

Agregue una nueva entidad a la sala de base de datos y use su PrimaryKey como ForeignKey

En este caso, crearemos una nueva entidad, Usuario, y agregue su clave principal, carné de identidadcomo una clave externa en Cuenta de usuario. Se requerirá una migración más compleja para realizar esta operación. Primero crearemos una nueva tabla de usuarios y agregaremos ID de usuario campo a nuestra UserAccount actual con el enlace ForeignKey.

Usuario:

Cuenta de usuario:

Veamos cómo se verá la migración en este caso:

Como podemos ver, aquí hemos realizado varias operaciones. Primero, cree una nueva tabla, Usuarioy agregando un nuevo campo al actual Cuenta de usuario.

Entonces tenemos que agregar ID de usuario, que es el usuario Clave primariahacer Cuenta de usuario como Clave externa. Eliminaremos el índice de esta columna, crearemos una nueva TABLA temporal, agregaremos un índice, insertaremos contenido de una Cuenta de usuario, suelte la tabla y finalmente cambie el nombre de temporal a original.

La migración de la base de datos no es algo que nos gustaría enfrentar, porque los datos del usuario pueden verse afectados por cualquier pequeño cambio en la estructura actual que lleve al colapso y la pérdida de información.

En este artículo, hemos examinado solo algunos de los casos básicos, pero esto debería cubrir los cambios más comunes en las entidades de base de datos. ¡Espero que sea de utilidad allí!

Puede encontrar el proyecto en el siguiente enlace:
https://github.com/groxx20/migrations

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *