Проверка и редактирование созданных сценариев

Autogenerate is a great first draft, not a final answer. Always review the script before you apply it anywhere. 🔍

Each script lives in the versions folder. Open it and read the upgrade and downgrade functions like any other code.

Inside the functions you will see calls on the op object, like op.create_table and op.add_column, each describing one schema change.

Autogenerate often misses renames, seeing them as a drop plus an add. That would silently delete the column data.

When a column is really being renamed, replace the drop and add with a single alter_column that preserves the data.

Confirm the downgrade truly reverses the upgrade. A broken downgrade leaves you stuck if you ever need to roll back.

Adding a non-nullable column to a table with rows will fail. Add it nullable first, fill values, then make it required.

Need to backfill values? Add an op.execute call with raw SQL between the schema steps to migrate existing data safely.

Before touching production, run the migration on a copy of real data. It surfaces failures while they are still cheap to fix.

Keep each migration focused on one logical change. Small scripts are far easier to review, test, and roll back cleanly.

Once edited and tested, commit the script. Never change a migration that has already shipped to production history.

You renamed a column, but autogenerate wrote a drop and an add. What is the danger?

You learned to review generated scripts, fix renames with alter_column, handle non-null columns, and test before shipping. 🎉