rake db: esquema: carga frente a migraciones

171

Una pregunta muy simple aquí: si las migraciones pueden volverse lentas y engorrosas a medida que una aplicación se vuelve más compleja y si tenemos mucho más limpio rake db:schema:loadpara llamar, ¿por qué existen las migraciones?

Si la respuesta a lo anterior es que las migraciones se usan para el control de versiones (un registro paso a paso de los cambios en la base de datos), entonces, a medida que una aplicación se vuelve más compleja y rake db:schema:loadse usa más, ¿continúan manteniendo su función principal?

Precaución:

De las respuestas a esta pregunta: rake db:schema:load eliminará datos en un servidor de producción, así que tenga cuidado al usarlo.

ruby-on-rails ruby-on-rails-3 migration sscirrus
fuente
55
+1 Nunca entendí el propósito de las migraciones; ¿Por qué no solo la versión controla el esquema?
alternativa
55
@alternative: las migraciones le permiten hacer otras cosas, como si necesita agregar una columna no nula, puede llenar esa columna de manera inteligente con datos en lugar de usar algún valor predeterminado.
Josh M.

Respuestas:

208

Las migraciones proporcionan cambios de pasos hacia adelante y hacia atrás en la base de datos. En un entorno de producción, se deben realizar cambios incrementales en la base de datos durante las implementaciones: las migraciones proporcionan esta funcionalidad con una reversión a prueba de fallas. Si ejecuta rake db:schema:loaden un servidor de producción, terminará eliminando todos sus datos de producción. Este es un hábito peligroso para entrar.

Dicho esto, creo que es una práctica decente ocasionalmente "colapsar" las migraciones. Esto implica eliminar migraciones antiguas, reemplazarlas con una única migración (muy similar a su schema.rbarchivo) y actualizar la schema_migrationstabla para reflejar este cambio. ¡Ten mucho cuidado al hacer esto! Puede eliminar fácilmente sus datos de producción si no tiene cuidado.

Como nota al margen, creo firmemente que nunca debe incluir la creación de datos en los archivos de migración. El seed.rbarchivo se puede utilizar para esto, o para rakear o desplegar tareas personalizadas. Poner esto en los archivos de migración combina la especificación del esquema de la base de datos con la especificación de datos y puede generar conflictos al ejecutar los archivos de migración.

Jesse Reiss
fuente
80
¡Gracias por informar que rake db: schema: load elimina todos los datos de producción!
Magne
2
En lugar de reemplazar las migraciones "colapsadas" por una nueva que imita el esquema, escribí una gema que simplemente las borra y solicita a los usuarios que las usen db:schema:loadsi intentan ejecutar db:migrateuna instalación nueva. @ clear_migrations
Yarin
Probablemente sea una respuesta obvia, pero antes del primer impulso a la producción, ¿recomendaría simplemente eliminar todas las migraciones y usar db.schema como la primera migración?
dtc
30

Me topé con esta publicación, eso fue hace mucho tiempo y no vi la respuesta que esperaba.

rake db:schema:loades genial por primera vez que pones un sistema en producción. Después de eso, debe ejecutar las migraciones normalmente.

Esto también lo ayuda a limpiar sus migraciones cuando lo desee, ya que el esquema tiene toda la información para poner en producción otras máquinas, incluso cuando limpió sus migraciones.

ereslibre
fuente
¿Entonces puede "limpiar" sus migraciones porque nunca tiene que usarlas? Suena como una afirmación extraña.
Abe Petrillo
No me queda claro cuál es el beneficio que db:schema:loadtiene aparte de afeitarse unos segundos una vez durante el ciclo de desarrollo. ¿Alguna vez trabajó con una aplicación que tardó más de 30 segundos en crearse? Actualmente estoy trabajando en una aplicación que tiene errores en sus archivos de migración y nunca migrará sin tener correcciones de errores o ejecutarse, db:schema:loadlo que me hace pensar en el esquema: la carga es para cuando algo salió mal con respecto al desarrollo de la aplicación.
Ninjaxor
Otro argumento que haría para mantener las migraciones es que el equipo central de Rails dirige a los usuarios instead of editing schema.rb, please use the migrations feature. Por lo tanto, si está ejecutando db:schema:loaden un archivo generado automáticamente que no tiene migraciones para generar automáticamente nuevamente, efectivamente está siguiendo la ruta de "editar" manualmente el esquema y deshabilitar las migraciones. Desearía tener una cita de la guía de rieles sobre esto, pero no discuten el esquema: carga, lo que se suma a mi frustración al decidir cómo abordar el esquema: función de carga. = /
Ninjaxor
Vine a esta página precisamente porque estoy de acuerdo con eso. Mi experiencia es que una vez que el sitio está en producción, es mucho más seguro usar migraciones para cambiarlo. ¡A pesar de esto, los comentarios del comienzo de db / schema.rb dicen exactamente lo contrario! (Tengo el problema al comienzo de cada proyecto porque olvido poner db / schema.rb en .gitignore ...)
usuario1251840
@AbePetrillo wow Me perdí estos comentarios por completo. Por supuesto que no, lo que quise decir es que puede limpiar las migraciones antiguas que se han ejecutado en todas las máquinas de producción si lo desea. A lo largo de los años siempre los mantuve cerca, pero mi declaración "te ayuda a limpiar tus migraciones cuando quieras" no significaba que "nunca tendría que usar migraciones". Entonces, cuando implemente una nueva máquina, ejecute rake db:schema:loaden lugar de rake db:migrate. Luego, a partir de ahí, puedes rake db:migrate.
ereslibre
9

Las migraciones también le permiten agregar datos a la base de datos. pero db: schema: load solo carga el esquema.

Shaunak
fuente
6

Porque las migraciones se pueden revertir y proporcionan una funcionalidad adicional. Por ejemplo, si necesita modificar algunos datos como parte de un cambio de esquema, deberá hacerlo como migración.

Jamie Penney
fuente
4

Como usuario de otros ORM, siempre me pareció extraño que Rails no tuviera una función de 'sincronización y actualización'. es decir, mediante el uso del archivo de esquema (que representa el esquema completo y actualizado), revise la estructura de base de datos existente y agregue / elimine tablas, columnas e índices según sea necesario.

Para mí, esto sería mucho más robusto, aunque posiblemente sea un poco más lento.

Dan James
fuente
1
La tarea de migrar la base de datos con datos de un esquema complicado a otro no es trivial algunas veces. Es posible que no se resuelva automáticamente y que los datos no se migren de manera coherente con un solo paso. La migración de rieles es maestra y el esquema depende. Esquema recreado automáticamente con cada migración pero no al revés.
Oklas
Las guías propias de Rails declaran explícitamente que schemaes el maestro, no las migraciones.
Drenmi
0

Ya publiqué como comentario, pero siento que es mejor poner los comentarios del archivo db / schema.rb aquí:

# 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).
#
# It's strongly recommended that you check this file into your version control system.

En realidad, mi experiencia es que es mejor poner los archivos de migración en git y no el archivo schema.rb ...

usuario1251840
fuente
0

rake db:migrateconfigurar las tablas en la base de datos. Cuando ejecuta el comando de migración, buscará en db / migrate / cualquier archivo ruby ​​y los ejecutará comenzando por el más antiguo. Hay una marca de tiempo al comienzo de cada nombre de archivo de migración.

A diferencia de rake db:migrateque ejecuta migraciones que aún no se han ejecutado, rake db:schema:loadcarga el esquema que ya se generó en db/schema.rbla base de datos.

Puede encontrar más información sobre los comandos de la base de datos de rastrillo aquí .

Nesha Zoric
fuente