EF6 Contrib: Operaciones de migración

 

Otra de las características que tenemos dentro de EF6 Contrib es la de agregar operaciones personalizadas de migración, por ahora ya hay unas cuantas que seguro serán de utilidad para algunas de vosotros y aquellas que  no están seguro que pronto estarán o bien os animo a escribirlas. La ultima ha venido de un pull request de Quique ( @quiu3 ) en el que ha incluido la posibilidad de agregar computed columns, os animo a ver el pull request para ver lo sencillo que es incluir nuevas migraciones.

Para hacer uso de estos elementos solamente tenemos que cambiar el generador a utilizar, por defecto en EF 6 Contrib solamente tenemos un generador para Sql Server. Establecer este generador es tan sencillo como se ve a continuación:

Por supuesto también se podría hacer utilizando un DbConfiguration, cualquier opción sería válida, a elegir. Hasta aquí esta pequeña entrada, espero que os sea de utilidad….

 

Saludos

Unai

Preview EF 6.1 Features: Transaction Handler

Una de las principales novedades en EF 6 y de la que hablamos aquí, en este mismo blog, unas cuantas veces hace referencia a la característica de “connection resiliency” gracias a la cual tenemos una forma simple de tener aplicaciones capaces de manejar los errores temporales que un cluster de sql server podría producir, sin tener para ello que escribir ningún tipo de código de reintentos. Sin embargo, había algún escenario que esta nueva característica no cubría como el escenario conocido por “Idempotent Issue”  producido cuando después de una ejecución de un IUD( Insert, Update, Delete ) obtenemos un connection failure  ya que no tenemos una forma segura de saber si en realidad esta escritura se ha realizado en la base de datos. La única forma de poder hacer algo es llevar un seguimiento del comando para garantizar la “idempotencia”. Por desgracia Sql Server no ofrece/dispone  de ningún mecanismo por lo que la tarea de realizar este seguimiento nos la tenemos que hacer nosotros. Aquí es dónde entra el trabajo del equipo de Entity Framwork, puesto que ha realizado esta tarea por nosotros, gracias a la cual cuando tenemos un connection failure en un IUD el sabrá si realizar un reintento del comando o bien si lo que ha pasado es que la notificación del commit no ha llegado correctamente.

¿Como activamos esta característica?

Nota: Durante la escritura de este post se ha usado la versión 6.1.0-alpha1-30121

 

Para activarla como hacemos desde la llegada de nuestra configuración en código es usar nuestras clases DbConfiguration para registrar este nuevo servicio, como podéis ver a continuación:

 

¿Cómo se hace el seguimiento?

Si nos fijamos un poco, cuando vemos la base de datos creada o usada por un contexto que tiene habilitada esta característica veremos una nueva tabla que nada tiene que ver con nuestro modelo, y al igual que la tabla de migraciones, empieza con un “_” para identificarla como una tabla de “fontanería”. Esta tabla es _TransactionHistory y contiene este seguimiento de comandos del que hablamos. Por supuesto, al igual que podemos customizar la tabla de migraciones también podremos hacer lo mismo con esta, fijaros que tenemos un TransactionContext del que podemos heredar.

 

Untitled

 

En esta tabla, irán apareciendo y desapareciendo entradas que permitirán identificar a los comandos que se están ejecutando en un determinado contexto, una vez que este contexto se destruye, sus entradas correspondientes desaparecerán.  Este log de transacciones también contiene otro elemento que hace que se limpie y consiste en un límite hardcoded establecido en CommitFailureHandler cuyo valor es 20, lo que quiere decir que cuando aparezcan 20 entradas de log para un mismo contexto estas entradas de log se limpiarán.

 

 

Internals

 

Creo que más o menos ha quedado clara la problemática y como necesitamos un sistema de tracking de nuestras transacciones para posteriormente poder actuar ante los problemas de idempotencia. ¿ Pero como ha sido posible esto internamente? Ya en EF 6 se introdujeron unos pocos interceptores para mediar en la ejecución de consultas y comandos para la base de datos, pero estos no eran suficientes puesto que para este nivel necesitábamos más interceptores a nivel de transacción y conexión, por ello, ahora mismo disponemos de los siguientes elementos nuevos.

  • IDbTransactionInterceptor: Interceptor que nos permite interceptar diferentes operaciones relativas a las transacciones y a la solicitud de conexiones, etc.
  • IDbConnectionInterceptor: Interceptor que nos permite saber  e interceptar diferentes elementos relativos a las conexiones, cuando se abren, se cierran, empiezan una transacción etc.

Gracias a estos nuevos interceptores, que podrían ser registrados igualmente en nuestro DbInterception, se puede realizar esta característica. Seguro que otras muchas cosas saldrán gracias a estos nuevos interceptores y seguro que a muchos de vosotros ya se os han ocurrido ideas.

 

saludos

unai