EF vNext-Migrations – I

Hace relativamente poco tiempo que salió a la luz, la primera CTP de lo que se conoce como EF Migrations, creo en el mes de agosto, y, justamente ahora, se ha publicado la segunda de las alpha de esta feature que tendremos disponible en la siguiente actualización del producto.  Aunque  en realidad, el concepto de “migraciones” no es nada nuevo, de hecho, es algo bastante común en nuestros desarrollos, sobre todo si la frecuencia de cambio es alta, existen algunas de herramientas que nos permiten hacer estos trabajos de una forma más ligera, como por ejemplo  Fluent Migrator (podéis ver un pequeño getting started), o Migrator .NET o MigSharp. Desde el equipo de EF se dieron cuenta de que esto es una parte fundamental del trabajo de los desarrolladores y, están creando out-of-box lo necesario para que dispongamos de esta funcionalidad. Junto con la información sobre esta nueva alpha también han publicado un pequeño walkthroug sobre como trabajar con las migraciones. Yo por mi parte, como no me gusta repetir lo que otros escriben, haré el mio, intentando contar también mis impresiones sobre el teme. Para este pequeño ejemplo partiremos de un pequeño insignificante modelo y su correspondiente unidad de trabajo tal y como lo vemos a continuación.

 

NOTA: Antes de empezar conviene recordar que EntityFramework.Migrations solamente funciona si se dispone de una base de datos SQLEXPRESS o en su defecto un alias apuntando a este nombre de instancia.

A mayores, hemos puesto en la configuración de nuestra aplicación la ruta con la base de datos con la que trabajamos, suele ser la opción más realista, aunque si queréis saltar este paso podéis dejar que el sistema de convenciones trabaje por vosotros.

 

<?xml version=«1.0« encoding=«utf-8« ?>

<configuration>

  <connectionStrings>

    <add name=«DBMigrations.CRMUnitOfWork«

         connectionString=«Server=.;Initial Catalog=CRMUnitOfWork;Integrated Security=true;MultipleActiveResultSets=true«

         providerName=«System.Data.SqlClient«/>

  </connectionStrings>

</configuration>

 

La idea inherente a las “migraciones”, es, disponer de un sistema que nos permita ir modificando una base de datos existente, ante cambios de nuestro modelo, de tal forma que, incluso pudieramos movernos entre distintas versiones de ella en la misma forma en la que nos movemos en versiones de modelos diferentes. Iremos viendo funcionalidades según vayamos avanzando con el post. Lo primero de todo será incluir el paquete de NuGet que nos permite trabajar con las Migraciones, este paquete se llama EntityFramework.Migrations.

 

Nota: El primer paquete que sacaron de esta Alpha 2 contenía un error en la cadena de dependencias ( no estaba incluida la dependencia con Sql Server Compact) y daba un error, aseguraros que la versión con la que trabajais es EntityFramework.Migrations 0.6.1.0.

Una vez instalado el paquete de migraciones en nuestro proyecto se incluirá una nueva carpeta llamada Migrations y dentro de ella se situará un archivo de configuración llamado Settings, cuyo contenido se puede ver a continuación:

 

La idea principal de esta clase es la de configurar ciertos elementos de nuestro sistema de migraciones, en concreto podemos ver si tenemos o no las migraciones automaticas activadas, sobre lo que hablaremos más adelante, el lenguaje a utilizar en la generación de código, por ahora solamente está soportado C#, y el tipo de proveedor con el que trabajaremos ( Sql Server o Sql Compact son los únicos disponibles por ahora). Como puede observar, la clase nos pide indicar el contexto a utilizar en su parámetro genérico, en nuestro caso estableceremos CRMUnitOfWork.

El primer paso está dado, ahora, empezarmos por crear nuestra primera migración, que consistirá en establecer la primera estructura de nuestra base de datos para el modelo de entidades que tenemos. Para ello, en la propia consola de “NuGet Package Manager” podemos ejecutar el comando “Add-Migration FirstSteep”, dónde FirstSteep es el nombre que le queramos dar a la migración.

 

 

Una vez ejecutado el comando, este nuevo paquete nos genera un elemento conocido como una DbMigration  y, puesto que es la migración inicial esta consta de la esetructura para crear la base de datos con la que pretende trabajar el modelo. A continuación se puede ver el código de esta nueva clase incorporada al proyecto.

 

Con estos pasos, en realidad aún no hemos creado la base de datos, para realizarlo, ejecutaremos otro comando llamando Update-Database, el cual, nos ejecutará la migración en la base de datos que indique la unidad de trabajo( se podría utilizar el flag –script para generar un fichero .sql en su defecto). La ejecución de este comando, además de la creación de la estructura que implica el modelo crea una tabla de sistema denominada __MigrationHistory la cual contiene la información de las distintas migraciones ejecutadas sobre esta base de datos y los hash de los diferentes modelos con los que se ha trabajado. Aunque por ahora esta feature no está soportada, en un futuro no muy lejano podremos movernos de “adelante hacia atrás” en las distintas migraciones que hagamos de nuestros modelos.

 

Bien, supongamos ahora, que modificamos la entidad Customer de nuestro modelo y agregamos a la misma una propiedad llamada Email. Este cambio implicaria también un cambio en nuestra base de datos, hay una nueva columna que agregar a la estructura de la tabla correspondiente.  Gracias a Migrations, podremos hacer esto de una forma simple, basta con volver a ejecutar otra vez el comando Add-Migration con el correspondiente nombre que le queramos dar a la migración, en nuestro caso AddEmailProperty, y actualizar la base de datos con Update-Database.

 

 

Bien, hasta aquí ya hemos visto algunas de las posibilidades, pero en realidad hay muchas más. El scaffolding que se genera cuando hacemos Add-Migration podemos tocarlo para agregar algunos elementos que no solamente estén relacionados con la estructura de una tabla sino que también podemos por ejemplo agregar algún índice ( cosa que no podemos hacer con el API de mapeo de code first por ejemplo). Así, si nos interesara por ejemplo que Email tuviera un índice unique podríamos modificar la migración anterior y agregar algo como lo siguiente:

 

Espero que esto os resultará intersante, en la siguiente entrada seguiremos con este tema, viendo como funcionan las migraciones automáticas y sobre todo los siguientes pasos que tomarán en el equipo de producto de EF con respecto a este tema.

 

Saludos

Unai