¿Es una buena idea purgar los viejos archivos de migración de Rails?

Question

He estado ejecutando una gran aplicación Rails durante más de 2 años y, día a día, mi carpeta de migración ActiveRecord ha crecido hasta más de 150 archivos.

hay modelos muy antiguos, ya no está disponible en la aplicación, todavía se hace referencia en las migraciones. Estaba pensando en eliminarlos.

¿Qué opinas? ¿Usualmente purgas migraciones antiguas de tu base de código?

Answer 1

Ellos son relativamente pequeñas, por lo que elegiría para mantenerlos, sólo para el registro.

Usted debe escribir sus migraciones sin hacer referencia a modelos, u otras partes de aplicación, ya que van a volver a usted frecuenta;)

Salida estas directrices:

http://guides.rubyonrails.org/migrations.html#using-models-in-your-migrations

Answer 2

¿Por qué? A menos que haya algún tipo de problema con el espacio en disco, no veo una buena razón para eliminarlos. Supongo que si estás absolutamente seguro de que nunca volverás a retroceder nunca más, entonces puedes. Sin embargo, parece que ahorrar algunos KB de espacio en disco para hacer esto no valdría la pena. Además, si solo desea eliminar las migraciones que hacen referencia a los modelos anteriores, debe revisarlos todos a mano para asegurarse de no eliminar nada que todavía esté siendo utilizado en su aplicación. Mucho esfuerzo para poco beneficio, para mí.

Answer 3

vez que llegué a un sitio de lanzamiento importante, voy a rodar las migraciones en un solo y nuevo comienzo. Me siento sucia una vez que los números de versión de migración se levantan alrededor de 75.

Answer 4

Sí. Supongo que si eliminó completamente cualquier modelo y tabla relacionada también de la base de datos, entonces vale la pena ponerlo en migración. Si la referencia del modelo en la migración no depende de ninguna otra cosa, puede eliminarla. Aunque esa migración nunca volverá a ejecutarse porque ya se ejecutó e incluso si no la elimina de la migración existente, cada vez que migre la base de datos nueva, causará un problema.

Por lo tanto, es mejor eliminar esa referencia de la migración. Y refactore/minimice las migraciones a uno o dos archivos antes del lanzamiento grande a la base de datos en vivo.

Answer 5

Está bien para eliminar las migraciones anteriores una vez que se sienta cómodo, no serán necesarias. El propósito de las migraciones es tener una herramienta para hacer y deshacer cambios en la base de datos. Una vez realizados los cambios y en producción durante un par de meses, es probable que no los necesite de nuevo. Me parece que después de un tiempo son simplemente cruft que desordenan su repositorio, búsquedas y navegación de archivos.

Algunas personas se ejecutarán las migraciones desde cero para volver a cargar su base de datos dev, pero eso no es realmente lo que están destinados. Puede usar rake db:schema:load para cargar el esquema más reciente y rake db:seed para completarlo con datos de inicialización. rake db:reset hace las dos cosas por usted. Si tiene extensiones de bases de datos que no se pueden volcar a schema.rb, puede usar el sql schema format for ActiveRecord y ejecutar rake db:structure:load.

Answer 6

Personalmente, me gusta mantener las cosas ordenadas en los archivos de migraciones. Creo que una vez que haya implementado todos sus cambios, realmente debería analizar el archivo de las migraciones.La única dificultad que he enfrentado con esto es que cuando Travis corre corre un db:migrate, por lo que estos son los pasos que he utilizado:

1. Mover migraciones históricas /db/migrate/-/db/archive/release-x.y/

2. Crear una nueva migración archivo manualmente utilizando el número de versión de la última migración de ejecución en el directorio /db/archive/release-x.y y cambie la descripción a algo así como from_previous_version. Usar el número de la versión anterior significa que no se ejecutará en su máquina de pinchar y estropeará.

3. Copiar los contenidos schema.rb desde el interior de la sección ActiveRecord::Schema.define(version: 20141010044951) do y pegarlo en el método de la lista de cambios from_previous_versionchange

4. marque todos los que dentro y Robert debería ser el hermano de su padre.

La única otra consideración sería si sus migraciones crean ningún dato (mis escenarios de prueba contener todos sus propios datos, de modo que no tengo este problema)

Answer 7

The Rails 4 Way página 177: Sebastian dice .. .

un hecho poco conocido es que se puede extraer archivos de migración de edad (mientras manteniendo los más nuevos) para mantener la carpeta db/migrate a un tamaño manejable . Puede mover las migraciones anteriores a una carpeta db/archived_migrations o algo así. Una vez que recorte el tamaño de su carpeta de migraciones, use la tarea rake db:reset en (re) cree su base de datos desde db/schema.rb y cargue las semillas en su entorno actual.

Answer 8

de vez en cuando purgar todas las migraciones, que ya han sido aplicadas en la producción y veo al menos 2 razones para esto:

1. carpeta más manejable. Es más fácil detectar si se agrega alguna nueva migración.
2. Resultados de búsqueda de texto más limpios (La búsqueda de texto global dentro de un proyecto no genera toneladas de coincidencias inútiles debido a la migración anterior, por ejemplo, cuando alguien creó una columna hace 3 años).

Answer 9

Estoy de acuerdo, no tiene valor en más de 100 migraciones, la historia es un desastre, no hay una manera fácil de seguir el historial en una sola tabla y agrega confusión a la búsqueda de archivos.Simplemente Muda OMI :)

He aquí una guía de 3 pasos para aplastar todas las migraciones en el esquema idéntico al producción:

Paso 1: esquema de la producción

# launch rails console in production 
stream = StringIO.new 
ActiveRecord::SchemaDumper.dump(ActiveRecord::Base.connection, stream); nil 
stream.rewind 
puts stream.read 

Ésta es la copia -permitible para migraciones, menos el encabezado obvio

Paso 2: m Hacer las migraciones sin que se ejecute en producción

Esto es importante. Use la última migración y cambie su nombre y contenido. ActiveRecord almacena el número de fecha y hora en su tabla schema_migrations para que sepa qué se ejecutó y qué no. Reutiliza el último y pensará que ya se ha ejecutado.

Ejemplo: rename 20161202212203_this_is_the_last_migration -> 20161202212203_schema_of_20161203.rb

y poner el esquema de allí.

Paso 3: verificar y solucionar problemas de

Localmente, rake db: gota, rake db: crear, rake db: migrate

Compruebe que esquema es idéntico. Un problema que nos encontramos fue de fecha y hora "ahora()" en el esquema, esta es la mejor solución que pude encontrar para ello: https://stackoverflow.com/a/40840867/252799

Answer 10

Ver http://edgeguides.rubyonrails.org/active_record_migrations.html#schema-dumping-and-you

migraciones son no una representación de la base de datos: o bien structure.sql o schema.rb es. Las migraciones también son , no, un buen lugar para configurar/inicializar datos. db/seeds o una tarea de rake son mejores para ese tipo de tarea.

¿Qué son las migraciones? En mi opinión, son instrucciones sobre cómo cambiar el esquema de la base de datos, ya sea hacia adelante o hacia atrás (mediante una reversión). A menos que exista un problema, deben ejecutarse solo en los siguientes casos:

1. En mi máquina de desarrollo local como una forma de probar la migración y escribir el archivo de esquema/estructura.
2. En máquinas de desarrollador colega como una forma de cambiar el esquema sin soltar la base de datos.
3. En las máquinas de producción como una forma de cambiar el esquema sin soltar la base de datos.

Una vez que se ejecutan, debería ser irrelevante. Por supuesto, los errores suceden, por lo que definitivamente desea mantener las migraciones durante unos meses en caso de que necesite deshacerse.

entornos de CI no siempre necesidad de ejecutar migraciones. Disminuye la velocidad de su entorno de CI y es propenso a errores (como dice la guía Rails). Dado que sus entornos de prueba solo tienen datos efímeros, en su lugar debe usar rake db:setup, que se cargará desde schema.rb/structure.sql e ignorará por completo sus archivos de migración.

Si está utilizando control de código fuente, no hay ningún beneficio en el mantenimiento de las migraciones antiguas alrededor; son parte del historial de fuentes. Puede que tenga sentido ponerlos en una carpeta de archivo si esa es tu taza de café.

Con que todos Dicho esto, creo firmemente que tiene sentido para purgar las migraciones antiguas, por las siguientes razones:

• Podrían contienen código que es tan viejo que ya no se ejecutará (como si ha quitado un modelo). Esto crea una trampa para otros desarrolladores que quieran ejecutar rake db:migrate.
• Ellos se ralentizará grep tareas -como son irrelevantes y más allá de una cierta edad.

¿Por qué son irrelevantes? Una vez más por dos razones: el historial se almacena en el control de origen y la estructura de la base de datos real se almacena en structure.sql/schema.rb. Mi regla de oro es que las migraciones de más de 12 meses son completamente irrelevantes. Los elimino Si hubiera alguna razón por la que quería deshacer una migración anterior a esa, estoy seguro de que la base de datos ha cambiado lo suficiente en ese momento como para justificar la escritura de una nueva migración para realizar esa tarea.

Así cómo te deshaces de las migraciones? Estos son los pasos que sigo:

1. eliminar los archivos de migración
2. Escribe una tarea rastrillo para eliminar sus filas correspondientes de la tabla schema_migrations de su base de datos.
3. Ejecute rake db:migrate para regenerar structure.sql/schema.rb.
líneas
4. Validar que lo único que cambió en structure.sql/schema.rb se elimina correspondientes a cada una de las migraciones ha eliminado.
5. Despliegue, luego ejecute la tarea de rake desde el paso 2 en producción.
6. Asegúrese de que otros desarrolladores ejecuten la tarea de rake desde el paso 2 en sus máquinas.

El segundo elemento es necesario para mantener el esquema/estructura precisa, que, una vez más, es lo único que realmente importa aquí.