Liquibase-Incorporación del histórico de cambios en una BBDD existente

1
8417

Liquibase-Incorporación del histórico de cambios en una BBDD existente

0. Índice de contenidos.

1. Introducción

En el anterior tutorial haciamos una pequeña introducción sobre que es Liquibase, como funciona y que aporta a nuestros desarrollos, partiendo del punto de vista de una nueva bbdd, donde Liquibase se encarga de realizar cada uno de los cambios desde el primer momento. De esta manera en el histórico de cambios quedarán registrados todas las modificaciones de la bbdd desde su creación.

En esta ocasión os muestro como realizar un proceso de migración con Liquibase a partir de una base de datos existente. El proceso es sencillo y por eso el objetivo
del tutorial es realizar la migración generando un histórico de cambios como si de una nueva bbdd se tratase. Una vez finalizada la migración obtendremos por un lado, un changelogs.xml (fichero con el conjunto de cambios) inicial de una bbdd en un estado concreto y por otro habremos incorporado a la bbdd origen un histórico
de cambios con todas las modificaciones realizadas hasta ese estado.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware : Portátil Mac Book Pro 15″ (2,6 Ghz Intel Core i7, 4 GB DDR3)
  • Sistema Operativo:Mac OS X Snow Leopard 10.6.4
  • Liquibase 1.9.5
  • MySQL 5.0.5

3. Situación inicial

El ejemplo expuesto a continuación es un muy simple, pero los pasos a seguir serían los mismos si el modelo de datos fuese más complejo, teniendo en cuenta que Liquibase en esta situación, solo es un intérprete. Si el modelo de datos del que partimos no está correctamente diseñado el conjunto de cambios y el histórico se generarán con errores.

  • BBDD Origen;

    Es la bbdd de de la que partimos y a la que incluiremos el histórico con los cambios realizados hasta su situación actual.

    Como vemos la bbdd solo tiene creada dos tablas con sus datos correspondientes. Estos serian los cambios que contendrá el histórico después del proceso de migración.

4. Migración

A continuación cuento como realizar el proceso de migracón paso a paso:

  • Paso 1

    El primer paso consiste en generar el changelogs.xml a patir de la base de datos. Para ello desde la línea de comandos ejecutamos:

    liquibase  
    --driver=com.mysql.jdbc.Driver  
    --classpath=/Users/sgdiaz/mysql-connector-java-5.0.5.jar  
    --changeLogFile=/Users/sgdiaz/changelog.xml   
    --url="jdbc:mysql://localhost:3306/liquibase_origen"   
    --username=liquibase_origen   
    --password=liquibase_origen   
    generateChangeLog  
    

    Comprobamos la generación del changelogs.xml:

      
          
          
              
                  
                      
                  
                  
                      
                  
                  
                      
                  
              
          
          
          
              
                  
                      
                  
                  
                      
                  
                  
                      
                  
                  
                      
                  
              
          
     
    

  • Paso 2

    El segundo paso consiste en generar un dump de la bbdd origen cuyo resultado será un script.sql que contendrá cada uno de los registros que pueblan la bbdd. Por ejemplo liquibase_origen.sql, el resultado seria:

    INSERT INTO CLIENTES (id,nombre,apellidos) VALUES   
     (5,'Jaime','Mayor Sanchez'),  
     (4,'Victor','Alcantara Hernandez'),  
     (3,'David','Crespo Cuesta'),  
     (2,'Pedro','Ramirez Lopez'),  
     (1,'Juan','Garcia Perez');  
    INSERT INTO PROVEEDORES (id,nombre,direccion,codPostal) VALUES   
     (5,'proveedor5','Avenida de castilla',28056),  
     (4,'proveedor4','Avenida de los fresnos 80',12856),  
     (3,'proveedor3','C \\ coruña 25',13058),  
     (2,'proveedor2','C \\ de los rios 3',28965),  
     (1,'proveedor1','C \\ de la esgaravita 76',28907);  
    

    A continuación incluremos en el fichero de cambios un changeset que se encargará de ejecutar dicho script.

      
          
          
              
                  
                      
                  
                  
                      
                  
                  
                      
                  
              
          
          
          
              
                  
                      
                  
                  
                      
                  
                  
                      
                  
                  
                      
                  
              
          
          
                         
          
          
      
    
  • Paso 3

    El tecer paso consiste en ejecutar un update del changelogs.xml generado con liquibase sobre una bbdd nueva, «liquibase_nueva» por ejemplo. La bbdd a la que apuntemos ha de estar creada de antes de realizar el update. Desde linea de comando ejecutamos:

    Comprobamos en bbdd que se han creado correctamente las tablas con los datos. Además observamos como Liquibase ha creado dos nuevas tablas en dicha bbdd, DATABASECHANGELOG y DATABASECHANGELOGLOCK. La primera es el histórico propiamanete dicho , la segunda es una tabla que utiliza Liquibase para escribir o no en el histórico evitando ejecutar dos changelogs distinitos al mismo tiempo.

    Comprobamos que en la tabla DATABASECHANGELOG se han incluido un registro por cada conjunto de cambios:

    Por tanto ahora mismo ya tenemos generado un changelogs.xml de una base de datos existente con un histórico que refleja cada uno de los cambios realizados hasta el estado actual.

  • Paso 4

    El cuarto y último paso es incorporar el histórico generado en el paso anterior en la bbdd datos origen (liquibase_origen). Para ello solo tenemos que generar un script.sql a partir de la bbdd nueva (liquibase_nueva) que contenga las dos tablas generadas por Liquibase al realizar el update.

    USE liquibase_origen;  
    CREATE TABLE  DATABASECHANGELOG (  
      `ID` varchar(63) NOT NULL,  
      `AUTHOR` varchar(63) NOT NULL,  
      `FILENAME` varchar(200) NOT NULL,  
      `DATEEXECUTED` datetime NOT NULL,  
      `MD5SUM` varchar(32) DEFAULT NULL,  
      `DESCRIPTION` varchar(255) DEFAULT NULL,  
      `COMMENTS` varchar(255) DEFAULT NULL,  
      `TAG` varchar(255) DEFAULT NULL,  
      `LIQUIBASE` varchar(10) DEFAULT NULL,  
      PRIMARY KEY (`ID`,`AUTHOR`,`FILENAME`)  
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1;  
      
    INSERT INTO DATABASECHANGELOG (ID,AUTHOR,FILENAME,DATEEXECUTED,MD5SUM,DESCRIPTION,COMMENTS,TAG,LIQUIBASE) VALUES   
     ('1285323140267-1','sgdiaz (generated)','/Users/sgdiaz/changelogs.xml','2010-09-24 13:36:50','cf3d82c3690de2c61c70794041a4f3','Create Table','',NULL,'1.9.5'),  
     ('1285323140267-2','sgdiaz (generated)','/Users/sgdiaz/changelogs.xml','2010-09-24 13:36:50','75a4f6259a8c97f5899f267619a471ce','Create Table','',NULL,'1.9.5'),  
     ('1285323140267-3','sgdiaz (generated)','/Users/sgdiaz/changelogs.xml','2010-09-24 13:40:05','3d4480af67a9a434f411d888477aa4','SQL From File','',NULL,'1.9.5');  
      
    CREATE TABLE  DATABASECHANGELOGLOCK (  
      `ID` int(11) NOT NULL,  
      `LOCKED` tinyint(1) NOT NULL,  
      `LOCKGRANTED` datetime DEFAULT NULL,  
      `LOCKEDBY` varchar(255) DEFAULT NULL,  
      PRIMARY KEY (`ID`)  
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1;  
      
    INSERT INTO DATABASECHANGELOGLOCK (ID,LOCKED,LOCKGRANTED,LOCKEDBY) VALUES   
     (1,0,NULL,NULL);
    

    Ahora solo tenemos que ejecutar dicho script sobre la base de datos origen lo que hará que se cree el histórico en dicha bbdd. Por tanto una vez ejecutado este script habremos incorporado un histórico de cambios a una bbdd existente manteniendo todos los cambios desde su inicio y la próxima vez que se realize un update sobre dicha bbdd Liquibase solo tendrá en cuenta los changeset nuevos que no estén en dicho histórico.

5. Conclusiones.

Como hemos visto, de una manera sencilla, podemos incorporar Liquibase en una bbdd existente suponiendo un impacto mínimo en nuestros desarrollos. Además creo que este proceso nos supone dos grandes ventajas:
La primera es que a partir de este momento tendremos un histórico de los cambios realizados en dicho modelo de datos.
La segunda es que obtenemos un conjunto de cambios inicial que puede servirnos como punto de partida para cada uno de los desarrolladores que forman parte del equipo. De esta manera en un instante cualquier nuevo desarrollador que se incorpore al proyecto podrá montar la bbdd ejecutando un update sobre el changelogs.xml generado.

Espero que os sirva de utilidad.

Un saludo.

Saúl García Díaz

1 COMENTARIO

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad