¿Por qué cambia schema.rb (a los ojos de Git) cuando ejecuta rake db: migrate?

Question

Este es un pequeño general que conozco, pero me ha estado molestando muchísimo. He estado trabajando en muchos proyectos de raíles de forma remota con Git y cada vez que hago un git pull y veo que hay algún tipo de cambio de datos (migración o cambio de schema.rb) hago un rake db:migrate.

Generalmente funcionan bien y puedo seguir trabajando. Pero si hace un git pull y luego git status, su directorio de trabajo está limpio (obviamente) luego haga un rake db:migrate (obviamente cuando haya cambios) y otro git status y de repente su db/schema.rb ha cambiado. He estado haciendo un git checkout inmediatamente para restablecer a la última versión confirmada del archivo schema.rb, pero ¿por qué debería ser necesario? ¿Qué están haciendo los rieles? ¿Actualizando una marca de tiempo? Parece que no puedo entender cuál es la diferencia, pero ¿tal vez me estoy perdiendo algo?

Answer 1

El esquema permite a las máquinas ejecutar rake db:schema:load cuando se configuran por primera vez en lugar de tener que ejecutar las migraciones, que pueden estar desactualizadas si se renombran o eliminan los modelos, etc. Se supone que se debe actualizar después de una migración, y usted siempre desea la última versión registrada en el control de la fuente.

Answer 2

schema.rb refleja el esquema de su base de datos por lo que cuando migra (con cambios) sigue que su esquema también cambia para reflejar su cambio de db. Normalmente agrego schema.rb a nuestro gitignore, junto con database.yml (probablemente porque en lugar de usar schema: carga como el de abajo, suelo hacer un dump de sql al clonar una aplicación existente, pero así soy yo)

Answer 3

El final de db:migrate es volcar el esquema. Tendrá diferentes marcas de tiempo (debería decírselo), y diferentes versiones de rieles/gemas de base de datos le darán formatos ligeramente diferentes. Es una molestia menor ver esto todo el tiempo.

Le recomiendo que agregue schema.rb a su archivo .gitignore.

Answer 4

El orden de los atributos en el volcado refleja el orden de los atributos en la base de datos, y puede desalinearse si una persona ha estado jugando localmente con migraciones, ejecutándolas hacia adelante y hacia atrás manualmente, y editando cosas a obtenerlos solo así. Es posible crear un estado donde el orden de los atributos en schema.rb del empujador sea diferente de lo que todos los demás verán cuando ejecuten las migraciones.

Si es fácil recrear sus datos de desarrollo, simplemente reconstruya la base de datos desde schema.rb, luego todos están sincronizados (pero recuerde que no puede volver a cargar los datos de un volcado de SQL que también crea la tabla). recrear el problema. Tiene que ser un volcado/carga de solo datos). En el peor de los casos, puede crear una migración para eliminar la columna y otra para volver a agregarla.