2010-12-03 8 views
5

He estado escribiendo algunas migraciones últimamente que caen bajo el paraguas Migración irreversible. Pero no son el fin del mundo irreversible. Podrías tirarlos hacia atrás si quieres. El escenario que tengo en este momento es cambiar una relación de uno a muchos a una relación de muchos a muchos. Implica descartar una columna y crear una nueva tabla de unión. (así como dos líneas en los modelos).Migraciones irreversibles: ¿advertencia y confirmación en lugar de abortar?

Estaba pensando, en lugar de abortar la migración descendente, podría decir algo como "Esta migración es [INSERTAR MENSAJES ASESINADOS AQUÍ], ¿está seguro de que desea continuar? S/N" y luego retrotraer la migración si ellos eligen? ¿Simplemente coloque la migración dentro de una declaración if?

Es bastante fácil hacer que las migraciones sean irreversibles, y generalmente hay una buena razón (por ejemplo, no se pueden recuperar los datos). ¿Estos problemas suelen resolverse simplemente escribiendo una migración que lo hace de forma manual?

En mi mente noobish estaría bien tener un medio feliz. ¿Es sabio? Tal vez simplemente no entiendo cuándo hacerlos irreversibles en primer lugar.

Respuesta

1

Siempre trato de hacer la migración reversible si es posible. La única vez que creo que me he encontrado con problemas es cuando pasas de un modelo de datos groseramente definido a uno más fino, y luego de regreso. Sin embargo, no veo ninguna razón para no usar su solución, dependiendo, por supuesto, de las consecuencias de la migración. Tampoco hay nada que impida que la persona que está ejecutando la migración hacia abajo comente el error planteado y escriba su propio código para revertir la migración, pero es mucho más seguro para usted, la persona que escribe el cambio del modelo de datos sabe cómo volver a la estado anterior en lugar de ellos adivinando.

+0

"es mucho más seguro para usted, la persona que escribe el modelo de datos cambia para saber cómo volver a pasar al estado anterior en lugar de que adivinen ". ¡Exactamente! Es por eso que me sorprendió un poco que esta opción no estuviera disponible ya que es completamente posible que alguien anule la excepción que usted escribe. – Nick

+0

Ruby tiene muy pocas reglas. considere: http://gfredericks.com/gfrlog/post/51 Por lo tanto, confiamos en el sentido común, la convención y las buenas pruebas :) –

1

Acabo de tropezar con esta publicación anterior aquí, ya que tuve problemas de alguna manera con la misma pregunta.

Tuve el otro caso: pasar de muchos a muchos (HABTM) a uno a muchos. Por supuesto, quería eliminar la tabla de unión luego. Realmente tenía miedo de olvidarme de copiar los datos de la tabla de unión durante la implementación. Así que decidí incluir una "advertencia" de migración:

class DataMigrationWarning < ActiveRecord::Migration 
    def change 

    puts("********************** Data Migration Warning **********************") 
    puts("Dont forgett to save the data.") 
    puts("Next UP migration will delete table XYZ.") 
    puts("Next DOWN migration will delete field A in table BCD.") 
    puts("press y for continue.") 
    puts("press anything else for stopping.") 

    if STDIN.gets.chomp == "y" 
     puts("Ok then!") 
    else 
     fail 
    end 

    # More detailed explanation... 

    end 
end 

La línea de comandos a continuación, sólo se le mostrará todas las cosas allí y espera una entrada del usuario. y solo irá a la próxima migración. todas las otras entradas detendrán la migración y todo lo siguiente.

El proceso se veía en el final como:

  1. Migración: Crear nuevo campo para la nueva belong_to
  2. migración Advertencia
  3. Migración: Eliminar vieja tabla de unión
+0

¡Exactamente lo que estaba buscando! Nada como una gran advertencia para hacer las cosas en serio. ¡Gracias! – Andreas

Cuestiones relacionadas