Solo para dar un poco más de contexto a la pregunta, tengo una aplicación web (asp mvc) que básicamente ajusta las operaciones CRUD a una instancia de MongoDb, lleva a cabo validación y cierta lógica comercial antes de verificar el modelo y enviado a ser almacenado, recuperado, etc.Manejo de migraciones con MongoDb
Ahora un problema que tenemos es que en la nueva versión los modelos han cambiado pero los datos existentes no, aquí hay un ejemplo: (es C# específico pero la pregunta realmente es el lenguaje agnóstico)
public class Person
{
public Guid Id {get; set;}
public string Name {get; set;}
public int Age {get;set;}
public string BadgeNo {get;set;}
}
public class Person
{
public Guid Id {get; set;}
public string Name {get; set;}
public int Age {get;set;}
public string EmployeeNo {get; set;} // Still contains same data as BadgeNo just called something different
}
Como se puede ver la estructura de los objetos han cambiado pero en Mongo i tierra t sigue distribuyendo un BadgeNo, no un EmployeeNo. En un terreno de SQL, normalmente tendríamos un script de migración que se ejecuta como parte del script de compilación, que cambiaría el esquema y actualizaría/insertaría/eliminaría cualquier dato adicional para ese delta.
Entonces, ¿cómo es mejor administrar este tipo de migraciones con Mongo? ¿Debo tener también un script que utilizo para actualizar todas las instancias dentro de Mongo? o hay alguna otra práctica preferida para hacer este tipo de cosas.
Cualquier consejo sobre el tema sería genial
=== === Editar
Parece que actualmente estoy queriendo ir con la opción de migración en lugar de un enfoque de eliminación gradual, por lo que con este en mente, ¿alguien puede recomendar alguna herramienta para ayudar en esta área, ya que de lo contrario cada migración (suponiendo un roll-in, roll-out) tendría que ser un ensamblaje precompilado de algún tipo con toda la lógica dentro. Estaba pensando algo a lo largo de las líneas de FluentMigrator pero en vez de trabajar con SQL estás trabajando con Mongo. Actualmente mis scripts de compilación están usando Nant, he visto algunas herramientas de ruby pero no estoy seguro de si hay algún equivalente de .net.
yo elegiría la opción 1 - y luego utilizar ese código para crear una utilidad de migración (una aplicación de línea de comandos, por ejemplo) que realiza el equivalente de la opción 2 más tarde por cargar y guardar todos los documentos en una colección que aún se encuentran en el versión antigua. –
Buena idea Sean, he actualizado mi respuesta. – Derick
El problema es que está escribiendo MUCHO código en exceso que deberá mantener solo para admitir versiones múltiples, e imagine que 20 versiones más adelante tiene 20 archivos para cada modelo que ha cambiado. Para mí, las segundas opciones parecen mejores ya que es más fácil moverse entre versiones (es decir, reversiones), no tengo problemas con pequeñas cantidades de tiempo de inactividad. Gracias por la respuesta, dejaré esto abierto un poco más ya que esperaba mucha gente para decir la Opción 2, pero esperaba obtener un poco más de información sobre cómo es mejor automatizar el segundo enfoque, es decir, dentro del script de compilación. – Grofit