Por qué necesita migraciones, no create_all

Las aplicaciones reales evolucionan, por lo que sus tablas también deben cambiar. Añadirá columnas, cambiará nombres de campos y eliminará los antiguos a medida que crezcan las funcionalidades. 🔄

Recuerde la limitación que vio antes: create_all solo crea las tablas que faltan. Nunca modifica una tabla que ya existe.

Una solución tentadora es eliminar la tabla y volver a crearla. Funciona en una demostración, pero elimina todas las filas, algo impensable en producción.

Ejecutar ALTER TABLE sin procesar manualmente en una base de datos activa es frágil. Un error tipográfico o un paso omitido puede corromper los datos sin posibilidad sencilla de deshacerlo.

Una migration es un script pequeño que mueve el esquema de una versión a la siguiente mediante pasos seguros y repetibles.

Cada migración tiene un identificador de versión y apunta a la anterior. Juntas forman un historial ordenado de todos los cambios del esquema.

Una migración define dos rutas: upgrade aplica el cambio y downgrade lo revierte si algo sale mal.

Flask-Migrate conecta su aplicación con Alembic, la herramienta que detecta cambios en el esquema y escribe los scripts de migración por usted.

Las migraciones registran la versión actual del esquema en una tabla llamada alembic_version, para que la herramienta siempre sepa en qué punto se encuentra.

Los mismos scripts de migración se ejecutan en su ordenador, en CI y en producción, de modo que todos los entornos terminan con un esquema idéntico.

Use create_all únicamente para el primer prototipo. En cuanto su modelo empiece a cambiar, pase definitivamente a las migrations.

Vio por qué create_all no puede evolucionar un esquema y cómo las migrations permiten cambios seguros, versionados y reversibles. 🎉