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.

Practice

1. What is the primary purpose of running python manage.py migrate in a Django production environment?

easy

A. To create new migration files based on model changes

B. To apply database schema changes defined in migration files

C. To start the Django development server

D. To reset the database to its initial state

Solution

1. Step 1: Understand the migrate command

   The migrate command applies changes to the database schema based on migration files already created.

2. Step 2: Differentiate from makemigrations

   makemigrations creates migration files, but migrate applies them to the database.

3. Final Answer:

   To apply database schema changes defined in migration files -> Option B

4. Quick Check:

   migrate applies changes = A [OK]

Hint: migrate applies changes, makemigrations creates files [OK]

Common Mistakes:

• Confusing migrate with makemigrations
• Thinking migrate resets the database
• Believing migrate starts the server

2. Which of the following is the correct command to create new migration files after changing Django models?

easy

A. python manage.py runserver

B. python manage.py migrate

C. python manage.py makemigrations

D. python manage.py flush

Solution

1. Step 1: Identify the command for creating migrations

   makemigrations scans model changes and creates migration files.

2. Step 2: Confirm other commands' purposes

   migrate applies migrations, runserver starts server, flush clears data.

3. Final Answer:

   python manage.py makemigrations -> Option C

4. Quick Check:

   makemigrations creates files = A [OK]

Hint: makemigrations creates files, migrate applies them [OK]

Common Mistakes:

• Using migrate instead of makemigrations to create files
• Confusing runserver with migration commands
• Using flush to manage migrations

3. Given the following sequence of commands in production:

python manage.py makemigrations
python manage.py migrate

What will happen if a model field was renamed but the migration was not created before running migrate?

medium

A. No changes will be applied to the database schema

B. An error will occur because migrate requires new migration files

C. The database schema will update correctly with the renamed field

D. The old field will be deleted automatically

Solution

1. Step 1: Understand migration dependency

   migrate applies changes only if migration files exist. Without new migration files, no schema changes happen.

2. Step 2: Effect of missing migration files

   If you rename a field but skip makemigrations, the database stays unchanged after migrate.

3. Final Answer:

   No changes will be applied to the database schema -> Option A

4. Quick Check:

   migrate needs migration files = C [OK]

Hint: Always run makemigrations before migrate to apply changes [OK]

Common Mistakes:

• Assuming migrate updates schema without migration files
• Expecting automatic field deletion
• Thinking migrate throws error without new migrations

4. You ran python manage.py migrate in production but got an error about conflicting migrations. What is the best way to fix this?

medium

A. Use python manage.py migrate --merge to resolve conflicts

B. Manually edit the database tables to match models

C. Ignore the error and restart the server

D. Delete all migration files and recreate them

Solution

1. Step 1: Identify cause of migration conflicts

   Conflicts happen when multiple migration branches exist. Django offers a merge option to fix this.

2. Step 2: Use the merge option

   migrate --merge helps combine conflicting migrations safely without deleting files or manual edits.

3. Final Answer:

   Use python manage.py migrate --merge to resolve conflicts -> Option A

4. Quick Check:

   migrate --merge resolves conflicts = D [OK]

Hint: Use migrate --merge to fix conflicts safely [OK]

Common Mistakes:

• Deleting migration files causing data loss
• Manually editing tables risking corruption
• Ignoring errors leads to bigger issues

5. In a production environment, you want to add a new non-nullable field to a large existing table without downtime. Which approach is safest?

hard

A. Add the field as non-nullable directly and run migrate

B. Skip migrations and add the field manually in the database

C. Drop the table and recreate it with the new field

D. Add the field with null=True, migrate, then update data and alter to null=False

Solution

1. Step 1: Understand downtime risks

   Adding a non-nullable field directly can lock the table and cause downtime in production.

2. Step 2: Use a two-step migration

   First add the field as nullable (null=True), migrate, then fill data, and finally alter to non-nullable (null=False).

3. Final Answer:

   Add the field with null=True, migrate, then update data and alter to null=False -> Option D

4. Quick Check:

   Two-step migration avoids downtime = B [OK]

Hint: Add nullable field first, then make non-nullable after data update [OK]

Common Mistakes:

• Adding non-nullable field directly causing downtime
• Dropping tables losing data
• Skipping migrations causing inconsistencies