Nota: Esto es cierto en lo que respecta a Rails 2.x. Puede que no sea cierto para los rieles 3, ya que no he pasado tanto tiempo con Rails 3 como me hubiera gustado.
Rails crea una tabla oculta especial llamada schema_migrations
. Esta tabla tiene una sola columna llamada version
. Y hay una fila en esta columna para cada migración que tenga. El valor es la marca de tiempo que coincide con la marca de tiempo del nombre de archivo de migraciones.
Cuando migra, busca todas sus migraciones en orden cronológico (también sucede que es orden alfabético debido a la convención de nomenclatura basada en timstamp). Para cada migración, busca una fila coincidente en la tabla schema_migrations
. Si no puede encontrar uno, ejecuta esa migración y agrega la marca de tiempo de la tabla. Si encuentra uno, asume que ya se ejecutó y simplemente lo omite.
El resultado es que 2 desarrolladores pueden realizar migraciones en cualquier orden, y está bien. Esto se debe a que Rails sabe exactamente qué migraciones se han ejecutado y cuáles no, independientemente de cuándo su base de datos las haya visto por primera vez.
Así que para hacer algo como esto, simplemente necesita una forma de almacenar permanentemente este estado sobre qué pasos se han dado y cuáles no.
Busca la última migración. Corre los que vienen después de eso. * Muy * ampliamente, es una DSL para escribir SQL (SQL reversible en 3.1). ¿Puedes ser mas específico? –
Funciona de muchas maneras ... ¿Qué aspecto específico de él se te escapa? –
Actualizó la pregunta. Estoy hablando específicamente de migrar y desmontar (es decir, rake migrate rollback). – Dan