ruby-on-rails - learn - ruby on rails code school

¿Cuándo(si) para consolidar las migraciones de ActiveRecord? (6)

Aunque estoy seguro de que todos tienen sus propias prácticas, existen algunas reglas implícitas en la forma en que funciona el sistema de migración:

Nunca realice cambios en las migraciones que otros desarrolladores o implementaciones previas hayan utilizado. En su lugar, realice una migración adicional para ajustar las cosas según sea necesario.
Nunca coloque dependencias a nivel de modelo en una migración. El modelo puede ser renombrado o eliminado en algún momento en el futuro y esto evitaría la migración. Mantenga la migración lo más autónoma posible, incluso si eso significa que es bastante simple y de bajo nivel.

Por supuesto, hay excepciones. Por ejemplo, si una migración no funciona, por la razón que sea, es posible que se necesite un parche para actualizarla. Incluso entonces, sin embargo, la naturaleza de los cambios efectuados por la migración no debería cambiar, aunque la implementación de los mismos sí puede cambiar.

Cualquier proyecto maduro de Rails probablemente tendrá alrededor de 200 a 1000 migraciones. En mi experiencia, es inusual ver un proyecto con menos de 30, excepto en las etapas de planificación. Después de todo, cada modelo generalmente necesita su propio archivo de migración.

Colapsando múltiples migraciones en una sola es un mal hábito para entrar cuando se trabaja en una pieza de software en evolución. Probablemente no colapses el historial de control de origen, entonces ¿por qué preocuparse por el historial de esquemas de la base de datos?

La única ocasión en la que puedo ver que es razonablemente práctico es si está bifurcando un proyecto viejo para crear una nueva versión o un spin-off y no quiere tener que llevar adelante una cantidad extraordinaria de migraciones.

A medida que avanzo en las iteraciones en mi aplicación * (s) acumulo migraciones. A partir de ahora hay 48 archivos de este tipo, que abarcan alrededor de 24 meses de actividad.

Estoy considerando tomar mi schema.rb actual y hacer que la línea de base.

También estoy considerando eliminar (sujeto al control de la fuente, por supuesto) las migraciones existentes y crear una nueva y única y brillante migración desde mi esquema actual. A las migraciones les gustan los símbolos, pero rake db:schema:dump usa cadenas: ¿me debería importar?

¿Eso parece sensato? Si es así, ¿en qué tipo de intervalo tendría sentido tal ejercicio? ¿Si no, porque no?

Y ¿me estoy perdiendo alguna tarea (¿rake?) Que haría esto por mí?

* En mi caso, todas las aplicaciones están basadas en Rails, pero cualquier cosa que use migraciones de ActiveRecord parece ajustarse a la pregunta.

Creo que hay dos tipos de migraciones:

los que hizo durante el diseño / desarrollo, porque cambió de opinión sobre cómo debería ser su DB;
los que hizo entre lanzamientos, que reflejan algunos cambios de comportamiento.

Me deshago del primer tipo de migraciones tan pronto como puedo, ya que en realidad no representan las versiones en funcionamiento, y guardo el segundo tipo, por lo que es posible, en teoría, actualizar la aplicación.

Acerca de los símbolos frente a las cadenas: muchos argumentan que solo se deben usar cadenas en las migraciones: los símbolos deben ser "manejables" a los objetos, y no deben usarse para representar nombres (nombres de columnas y tablas, en este caso). Esta es una mera consideración estilística, pero me convenció y ya no utilizo símbolos en las migraciones.

He leído acerca de otro punto para usar cadenas: " los símbolos ruby son pérdidas de memoria ", lo que significa que, cuando crea un símbolo, nunca se elimina durante toda la vida útil de la aplicación. Esto me parece completamente inútil, ya que todas sus columnas db se usarán como símbolos en una aplicación Rails (y ActiveRecord); la tarea de migrar tampoco durará para siempre, así que no creo que este punto tenga sentido.

La parte superior de schema.rb declara:

# This file is auto-generated from the current state of the database. Instead of editing this file, # please use the migrations feature of Active Record to incrementally modify your database, and # then regenerate this schema definition. # # 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 to check this file into your version control system.

Debo respaldar lo que [giorgian] dijo anteriormente sobre diferentes migraciones para diferentes propósitos. Recomiendo limpiar las migraciones orientadas al desarrollo junto con otras tareas que realiza cuando se ramifica para un lanzamiento. Eso funciona bien para mí, para mí y para los equipos pequeños. Por supuesto, mi aplicación principal se encuentra en la parte superior y entre otras dos bases de datos con sus propios esquemas que tengo que tener cuidado, así que utilizamos migraciones (en lugar de restauración de esquema) para una nueva instalación y esas necesitan sobrevivir ingeniería de lanzamiento.

No deberías estar eliminando migraciones. ¿Por qué crear el trabajo extra?

Las migraciones son esencialmente un conjunto de instrucciones que definen cómo crear la base de datos para respaldar su aplicación. A medida que construyes tu aplicación, las migraciones registran los cambios iterativos que realizas en la base de datos.

En mi humilde opinión, al restablecer la línea de base periódicamente, usted está haciendo cambios que tienen el potencial de introducir errores / problemas con su aplicación, creando trabajo adicional.

En el caso de que se agregue una columna por error y luego deba eliminarla en algún momento, solo cree una nueva migración para eliminar la columna adicional. Mi razón principal para esto es que cuando trabajas en un equipo no quieres que tus colegas tengan que seguir reconstruyendo sus bases de datos desde cero. Con este enfoque simple, usted (y ellos) pueden seguir trabajando de manera iterativa.

Como comentario aparte: al construir una base de datos nueva desde cero (sin ningún dato), las migraciones tienden a ejecutarse muy rápidamente. Un proyecto en el que estoy trabajando actualmente tiene 177 migraciones, esto no causa problemas al construir una nueva base de datos.

Sí, esto tiene sentido. Existe una práctica de consolidación de migraciones. Para hacerlo, simplemente copie el esquema actual en una migración y elimine todas las migraciones anteriores. Entonces tiene menos archivos para administrar y las pruebas pueden ejecutarse más rápido. Debe tener cuidado al hacer esto , especialmente si tiene migraciones que se ejecutan automáticamente en producción. En general, reemplazo una migración que sé que todos han ejecutado con el nuevo esquema.

Otras personas tienen formas ligeramente diferentes de hacer esto.

Por lo general, no he hecho esto hasta que tuvimos más de 100 migraciones, pero podemos lograrlo luego de unos meses de desarrollo. Sin embargo, a medida que el proyecto madura, las migraciones son cada vez menos frecuentes, por lo que es posible que no tenga que volver a hacerlo.

Esto va en contra de una mejor práctica: una vez que verifique una migración al control de origen, no la modifique. Hago una rara excepción si hay un error en uno, pero esto es bastante raro (1 en 100 tal vez). La razón es que una vez que están en libertad, algunas personas pueden haberlos ejecutado. Se registran como completados en el db. Si los modifica y registra una nueva versión, otras personas no obtendrán el beneficio del cambio. Puede pedirle a la gente que retroceda ciertos cambios y volver a ejecutarlos, pero eso frustra el propósito de la automatización. Hecho a menudo, se convierte en un desastre. Es mejor dejarlo solo.

Tener muchas migraciones es algo bueno. En combinación con su sistema de control de versiones, le permiten ver qué desarrollador realizó un cambio en la base de datos y por qué. Esto ayuda con la responsabilidad. Quitarlos solo hace que esto sea una gran molestia.

Si realmente desea obtener una nueva base de datos funcionando rápidamente, puede cargar el esquema con rake db: schema: cargar RAILS_ENV = your_environment y si desea obtener rápidamente la configuración de la base de datos de prueba, puede usar rake db: test: prepare

Dicho esto, si realmente desea consolidar sus migraciones, crearía una nueva migración que verifique si se realizó la última migración en su conjunto (por ejemplo: ¿existe la columna que agregó?) Y si no, entonces disparará. De lo contrario, la migración solo se agregará a la tabla de esquema como completada, por lo que no intentará volver a iniciarse.

Solo comunique lo que está haciendo al resto de su equipo para que entiendan lo que está sucediendo, no sea que disparen ciegamente un rastrillo. DB: migren y arruinen algo que ya tenían.