2009-04-01 13 views
15

Una aplicación de rieles que estoy desarrollando actualmente tiene alrededor de 35 migraciones hasta este punto. Dado que la aplicación comenzó como un experimento, hay una buena cantidad de abandono sin sentido en las migraciones, ya que iba y venía entre diferentes ideas.¿Es una buena idea colapsar viejas migraciones de rieles?

¿Hay algún inconveniente al contraer las migraciones 1-35 en una sola migración? Estaba planeando hacer esto haciendo que la primera migración cargue el esquema como está ahora y elimine todas las migraciones anteriores.

Actualmente soy la única persona que trabaja en este proyecto, si eso hace la diferencia.

Respuesta

11

Si usted tiene su código bajo control de origen (que hacer tienen su código bajo control de origen, ¿verdad ?) entonces diría que no hay ningún daño real, siempre que acepte que los cambios en el esquema van a requerir la restauración de viejas migraciones o nuevas migraciones. Solo asegúrate de comprender las implicaciones y de aceptarlas antes de establecer algo en piedra.

Su schema.rb actual puede formar la base de una nueva migración única que iniciará un nuevo conjunto.

Tenga en cuenta que si tiene operaciones de manipulación de datos en sus migraciones existentes, cargas de datos estáticos, por ejemplo, y/o posibles transformaciones posteriores, entonces deberán tratarse en alguna parte. Es algo que he tropezado varias veces ...

5

Me gustaría tenerlos alrededor. No se preocupe por tener que realizar muchas migraciones cada vez que un nuevo desarrollador verifique el proyecto. Siempre se puede ejecutar

rake db:schema:load 

que es mucho más rápido, en lugar de correr

rake db:migrate 
2

Si todas sus migraciones lo hacen, modifique las estructuras de su tabla, no me preocuparía por nada.

Tenga en cuenta que algunas migraciones agregan datos, tengo los que sembrar la base de datos con una cuenta de administrador y otros datos fijos, y el esquema no le dará esto.

Tenga en cuenta que es una mala idea hacer lo que hago con las migraciones ya que no utilizo las migraciones en la implementación. Por lo tanto, las migraciones colapsadas pueden ser una buena idea por un tiempo para mover esas migraciones de siembra de datos a tareas separadas de rake.

En revisión - Estoy haciendo eco de los puntos ya hechos. rake db:migrate VERSION -1

[Culpo al logotipo animado nueva distracción para dibujar el ojo fuera del texto]

5

veces migraciones pueden utilizar modelos que ya no existen o que crean tablas y más tarde los destruyeron a la pérdida de tiempo de CPU preciosa. Mejor para compilar todo en db/schema.rb y obtener sus desarrolladores ejecutar rake db:schema:load

-1

Para aquellos que, como yo, se encontró esta respuesta en búsqueda de una manera de restablecer una aplicación de nuevo a su estado original , esto es lo que debe hacer:

rm db/migrations/* 
rake db:drop 
rake db:schmea:dump 

Esto es útil si usted acaba de comenzar una aplicación y decide que desea reconstruir desde cero sin perder todos sus archivos.

1

No hay daño, y las migraciones colapsadas son una buena práctica y ayudan al rendimiento cuando las migraciones necesitan ejecutarse. Esto es ahora parte de schema.rb Rails:

# Note that this schema.rb definition is the authoritative source for your 
# database schema. If you need to create the application database on another 
# system, you should be using db:schema:load, not running all the migrations 
# from scratch. The latter is a flawed and unsustainable approach (the more migrations 
# you'll amass, the slower it'll run and the greater likelihood for issues). 

Nota como dice @ mike-Woodhouse, "Ten en cuenta que si tiene operaciones de manipulación de datos en sus migraciones existentes, cargas de datos estáticos, por ejemplo, y/o posibles transformaciones posteriores, entonces estas necesitarán ser manejadas en algún lado ".

Pero no deberías hacer nada de eso en tus migraciones de todos modos :) - Chad

Cuestiones relacionadas