En este mismo blog ya he hablado mucho con respecto a las migraciones y los inicializadores de Entity Framework, (aquí, aquí o aquí son algunas entradas ), así como su evolución desde las betas hasta la version 4.3.1 que tenemos en la actualidad como última version final. Pués bien, EF 5 incluye un pequeño cambio con respecto al trabajo con las bases de datos subyacentes que me parece muy sutil pero importante. Desde la llegada de las migraciones el proceso de comprobación de las bases de datos de trabajo se realizaba, una vez por appdomain, utilizando una tabla llamada _MigrationHistory establecida como tabla de sistema, en esta tabla, además de otros datos que no vienen a cuento,encontrabamos el hash del modelo con el que puede trabajar esa base de datos, si el hash del modelo y el almacenado en la base de datos coincide entonces estamos correctos para realizar el trabajo. En el caso de que no coincida, entonces dependera de nuestros inicializadores el saber que pasa, por ejemplo, si tenemos establecido MigrateDatabaseToLatestVersion podremos actualizar nuestra base de datos en el proceso de inicializacion. Aunque parezca que con esto tenemos suficiente, hay un caso que lo rompe, por ejemplo, cuando tenemos una base de datos que no ha sido creada por nosotros, por ejemplo, con alguno proceso de deployment automático o bien por un tercero sobre el que no tenemos control. En este casuística se nos da la situación de que la base de datos existe pero la tabla de migraciones no existe o incluso alguna de las tablas ( o ninguna ) de nuestro esquema de trabajo tampoco tendrían por que estar.
Si ponemos a funcionar nuestra aplicación basada en EF 4.X en estas condiciones, la misma, miserablemente nos dará una excepción como la siguiente:
“{"Invalid object name ‘XXX’."}”
Aunque parezca una estupidez, este casuística puede ser habitual si hablamos de hosters que ya nos proporcionan catálogos de base de datos pero sin esquema o incluso si queremos trabajar con alguna base de datos existentie como por ejemplo algun proveedor de roles, profile etc… Por suerte, en EF 5 este problema se ha resuelto y como podeis ver en las trazas de Intellitrace de las siguientes laterales se ha resuelto porque previo al proceso de trabajo con la base de datos se hace una revisión de la información de las vistas del sistema INFORMATION_SCHEMA. En función del resultado de las consultas a estas vistas se realizan las operaciones de creación, si es necesario, tanto de las tablas de esquema como de la tabla de sistema _MigrationHistory con lo que ya podremos trabajar tranquilamente.
Bueno, aquí acaba esta pequeña entrada, ya llevaba un tiempo sin escribir, la suerte del trabajo y que por estas fechas uno siempre suele estar atareado intentando sacar más libros a la luz, para no variar, este último también sobre EF, pero de una forma diferente a los anteriores que espero os guste un poco más.
Saludos
Unai