Database migration in production in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when you run python manage.py migrate in production?

You run python manage.py migrate on a live Django app. What is the immediate effect on the database?

A It rolls back the last migration applied to the database.

B It deletes all data in the database and recreates tables from scratch.

C It only checks for migration files but does not change the database.

D It applies all unapplied migrations in order, updating the database schema accordingly.

💡 Hint

Think about what migrations are designed to do in Django.

Running python manage.py migrate applies all migrations that have not yet been applied to the database, updating the schema without deleting data.

📝 Syntax

intermediate

Which command safely creates a new migration after model changes?

You changed a Django model in your app. Which command generates the migration file correctly?

A python manage.py makemigrations

B python manage.py migrate

C python manage.py migrate --create

D python manage.py makemigration

💡 Hint

One command creates migration files, the other applies them.

makemigrations creates migration files based on model changes. migrate applies them to the database.

🔧 Debug

advanced

Why does this migration fail in production?

You added a non-nullable field without a default to a model and ran makemigrations. Applying the migration in production fails. Why?

Django

class MyModel(models.Model):
    name = models.CharField(max_length=100)
    age = models.IntegerField()  # new field, no default, not nullable

A Because the migration file is missing a <code>RunPython</code> operation.

B Because existing rows have no value for the new non-nullable field, causing a NOT NULL constraint error.

C Because Django migrations do not support adding new fields.

D Because the database user lacks permission to alter tables.

💡 Hint

Think about what happens when you add a required column to a table with existing data.

Adding a non-nullable field without a default causes the database to reject the migration since existing rows have no value for that field.

🧠 Conceptual

advanced

What is the safest way to deploy a schema migration on a live Django app with heavy traffic?

You must add a new column to a large table without downtime. Which approach is safest?

A Add the new column as nullable first, deploy code using it, then backfill data and make it non-nullable in a later migration.

B Add the new column as non-nullable with no default and deploy immediately.

C Skip migrations and manually update the database schema after deployment.

D Drop the table and recreate it with the new schema during deployment.

💡 Hint

Think about how to avoid locking or errors on large tables.

Adding a nullable column first avoids locking and errors. Then code can use it safely before making it required.

❓ state_output

expert

What is the state of the Django migration table after running python manage.py migrate --fake appname 0003?

You run migrate --fake to mark migration 0003 as applied without running it. What does Django record in the migration history?

A Migration 0003 is applied normally, running all schema changes.

B Migration 0003 is skipped and not recorded in the migration history.

C Migration 0003 is marked as applied in the database, but its schema changes are not executed.

D Migration 0003 is rolled back if previously applied.

💡 Hint

The --fake option marks migrations as done without running them.

The --fake flag tells Django to record the migration as applied without executing its operations, useful for syncing state.