เหตุใดจึงต้องใช้การย้ายแบบแผนแทน create_all

Real apps evolve, so your tables must change too. You will add columns, rename fields, and drop old ones as features grow. 🔄

Remember the limit you met earlier: create_all only makes missing tables. It never touches a table that already exists.

One tempting fix is drop then recreate. It works in a demo, but it deletes every row, which is unthinkable in production.

Running raw ALTER TABLE by hand on a live database is fragile. One typo or missed step can corrupt data with no easy undo.

A migration is a small script that moves your schema from one version to the next in safe, repeatable steps.

Each migration has a version id and points to the one before it. Together they form an ordered history of every schema change.

A migration defines two paths: upgrade applies the change, and downgrade reverses it if something goes wrong.

Flask-Migrate connects your app to Alembic, the tool that detects schema changes and writes the migration scripts for you.

Migrations record the current schema version inside a table called alembic_version, so the tool always knows where you are.

The same migration scripts run on your laptop, in CI, and in production, so every environment ends up with an identical schema.

Use create_all only for the very first prototype. The moment your model starts changing, move to migrations for good.

Your table exists and you just added a column. Why not rely on create_all?

You saw why create_all cannot evolve a schema and how migrations bring safe, versioned, reversible changes. 🎉