.net fluent-nhibernate migration migratordotnet

.net - ¿Fluido NHibernate y migratordotnet juegan muy bien juntos?



fluent-nhibernate migration (4)

Me encanta Fluent NHibernate por construir mis bases de datos y hasta ahora no he encontrado una restricción que me haya detenido.

Sin embargo, en mi proyecto actual espero lanzar a producción muy temprano en el ciclo de vida del producto y, por lo tanto, espero que haya muchos pequeños cambios en el esquema de la base de datos a medida que avanzamos.

Me gustaría hacer un seguimiento de estos cambios DDL y DML en "migraciones", usando una herramienta como migratordotnet . Pero mi pregunta es: ¿es posible que estas dos herramientas (o herramientas similares) trabajen juntas?

En el espíritu de DRY, ¿cómo puedo derivar mis cambios de esquema de mis asignaciones en Fluent Nhibernate? es posible?

¿O es un mejor enfoque para dejar la generación de esquemas a una herramienta como migratordotnet y dejar a Fluent NHibernate con la responsabilidad de mapear solo? Hmm, esto parece una mejor separación de preocupaciones a nivel de herramienta.

¡Aclamaciones!

Estoy enfrentando el mismo problema. Aquí está mi flujo de trabajo actual que evita la actualización de esquema:

  • construir la base de datos desde cero (si se han realizado cambios)
  • mantener todos los datos de referencia en hojas de cálculo
  • recargar todos los datos a través de la línea de comando especial proyecto ''dataloader''

Este flujo de trabajo es bueno para el desarrollo, ya que la reconstrucción y el llenado de la base de datos desde cero cada vez que resuelve el problema de control de la versión de la base de datos. También proporciona una buena base para realizar pruebas en torno a su base de datos y los datos reales que está insertando.

Obviamente, esto no va a funcionar en la producción una vez que se ejecuta una base de datos en vivo que no se puede eliminar y reconstruir de una manera u otra. Esto es lo que estoy haciendo:

  • Una vez que finaliza un ciclo de desarrollo, tomo un clon de la base de datos de producción. La base de datos de Prod se hace de solo lectura para la duración de la actualización (está bien para mi aplicación ... no estoy seguro de que haya más aplicaciones críticas de tiempo)
  • Utilice la Comparación de SQL para migrar los cambios y los datos de dev a la base de datos prod.
  • Empuje esto para probar.
  • Si se pasa la prueba, empuje a la producción.

Esto no es ideal y hace uso del producto comercial de comparación de SQL. Me ha funcionado, pero me gustaría escuchar algunas ideas mejores.

Gordon

He tenido la misma pregunta en proyectos anteriores y nos decidimos a usar migratordotnet exclusivamente para las migraciones de nuestra base de datos y solo saltamos SchemaUpdate por completo.

Seguiré usando SchemaUpdate para prototipos rápidos, pero una vez que comience el proyecto en serio, solo uso migratordotnet.

Con la configuración de las migraciones para ejecutarse como parte de nuestras compilaciones nocturnas, migratordotnet funciona muy bien una vez que tenemos más de una persona trabajando en un proyecto.

Sí, en su mayoría. Estoy utilizando con éxito tanto FNH como migratordotnet para un cliente de escritorio grueso y funciona bastante bien. Tuve que modificarlo por dos cosas:

  1. Para permitir que la conexión sql se inyecte en TransformationProvider (o, más exactamente, en SQLiteTransformationProvider)

  2. extraiga las referencias a los otros TransformationProviders que no son de sqlite, ya que cuando intenté empaquetarlo con mi aplicación, se producirían varios errores al no poder encontrar Oracle, Postgres, etc.

  3. Esto es específico de sqlite: hackéelo para analizar mejor las declaraciones de la tabla de creación de sqlite. Desafortunadamente, no puede manejar las declaraciones de la tabla de creación CREATE TABLE FOO(id INT, ..., primary key(id)) (a diferencia de CREATE TABLE FOO(id INT PRIMARY KEY, ...) que sí maneja ). Combine esto con la forma en que realiza las eliminaciones de columnas (crear una nueva tabla sin columnas, transferir datos, eliminar el original y cambiar el nombre de una nueva a la original), esto significa que puede obtener un comportamiento bastante desagradable como la eliminación de la columna en una tabla, lo que hace que su columna de clave principal sea una columna de clave no primaria.

También me estoy topando con este mismo problema, donde no quiero tener que mantener las migraciones (usando migratordotnet) y mis archivos de mapeo de forma independiente. Lo único útil que he encontrado hasta ahora es el SchemaUpdate de NHibernate, pero eso no permite eliminar columnas o tablas. Para esos tipos de cambios, todavía necesitaría escribir manualmente una migración. En este momento me estoy inclinando hacia el uso de migratordotnet exclusivamente para cambios de base de datos en lugar de mezclar SchemaUpdate generar DDL y migraciones. Sin embargo, esto todavía parece propenso a errores, ya que podría convertir incorrectamente los cambios de capa de dominio / asignación en migraciones.