¿Verifica que el esquema de la base de datos de destino cumpla con lo que está en Entity Framework?

Question

Tenemos un proceso donde los guiones de nuestra base de datos cambian (y los utilizan Juneau) a la base de datos de nuestra aplicación fuera de banda con nuestra base de código. Son buenos contabilizando que las columnas nuevas son nulas y no borran los datos existentes, pero de vez en cuando se produce un cambio de nombre de columna que no se comunica por completo. Entonces harán algunos cambios al esquema de la base de datos en un servidor de prueba, actualizaremos Entity Framework para trabajar con esos cambios y luego confirmaremos nuestro código. Este proceso funciona bien, excepto para cuando sea el momento de implementarlo.

Tenemos TFS configurado para implementar la compilación exitosa en los servidores adecuados, pero no hay garantía de que la base de datos para ese entorno se haya actualizado. No nos importa si hay campos/tablas/vistas adicionales/etc. existen en la base de datos de destino, pero queremos cambiar la compilación para verificar que la base de datos contenga al menos todo lo que EF conoce.

Miré this question, pero no necesito que el esquema coincida exactamente. Además, no queremos que cree/modifique la base de datos directamente. Y this question parece que está tratando de lograr un ideal similar, pero aún no es lo que estamos buscando lograr. Solo queremos una especie de prueba de integración para verificar que nuestra versión de EF funcione con el esquema de destino.

Answer 1

Me pregunto por qué intenta implementar su aplicación sin cambios en la base de datos. Su aplicación depende de la base de datos, por lo que la implementación siempre debe realizarse después de la base de datos. Parece que va a invertir mucho tiempo para desarrollar la validación para corregir su proceso de implementación incorrecto (donde la reparación del proceso en sí es la solución correcta).

De todos modos, puede crear una "validación" de la base de datos, pero llevará algún tiempo. Si está utilizando un archivo EDMX, puede abrirlo como XML y leer su parte SSDL, que describe todas las tablas, columnas, relaciones, vistas esperadas (en forma de consultas SELECT SQL), procedimientos almacenados y funciones. Puede analizar esta parte XML y usar las vistas de la base de datos del sistema (sys.tables, sys.columns, ...) para consultar si estos objetos existen en la base de datos.

Otro enfoque puede ser el uso de la base de datos diff. herramienta para comparar su base de datos de prueba actual con la de destino. Esto requerirá la herramienta que se puede ejecutar desde la línea de comandos y deberá analizar su resultado para encontrar los cambios de última hora.