Database migration in production in Django - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a new migration file for your Django app.

Django

python manage.py [1] your_app_name

Drag options to blanks, or click blank then click option'

Amakemigrations

Bmigrate

Crunserver

Dcreatesuperuser

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'migrate' instead of 'makemigrations' to create migration files.

Running 'runserver' expecting migrations to be created.

Use makemigrations to create migration files that describe changes to your models.

2fill in blank

medium

Complete the command to apply migrations to the production database.

Django

python manage.py [1]

Drag options to blanks, or click blank then click option'

Amakemigrations

Bmigrate

Cshell

Dcollectstatic

Attempts:

3 left

💡 Hint

Common Mistakes

Running 'makemigrations' expecting database changes.

Using 'collectstatic' which is unrelated to database migrations.

The migrate command applies migration files to update the database schema.

3fill in blank

hard

Fix the error in the migration command to avoid downtime by running migrations without locking the database.

Django

python manage.py migrate --[1]

Drag options to blanks, or click blank then click option'

Aatomic

Bnoinput

Cfake

Dplan

Attempts:

3 left

💡 Hint

Common Mistakes

Using '--fake' which skips applying migrations but does not affect locking.

Using '--noinput' which only disables prompts.

The --atomic flag runs migrations inside a transaction to avoid partial updates and reduce downtime.

4fill in blank

hard

Fill both blanks to create a migration that adds a new field with a default value without locking the table.

Django

class Migration(migrations.Migration):
    dependencies = [
        ('app', '[1]'),
    ]

    operations = [
        migrations.AddField(
            model_name='model',
            name='new_field',
            field=models.CharField(default='default', max_length=100),
            [2]
        ),
    ]

Drag options to blanks, or click blank then click option'

A'0001_initial'

Bpreserve_default=False

Cpreserve_default=True

D'0002_auto'

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong migration dependency name.

Not setting preserve_default, which causes table locking.

Use the correct dependency migration name and set preserve_default=False to avoid locking the table when adding a field with a default.

5fill in blank

hard

Fill all three blanks to write a safe migration that renames a column without data loss.

Django

class Migration(migrations.Migration):
    dependencies = [
        ('app', '[1]'),
    ]

    operations = [
        migrations.RenameField(
            model_name='model',
            old_name='[2]',
            new_name='[3]',
        ),
    ]

Drag options to blanks, or click blank then click option'

A'0003_auto'

Bold_column

Cnew_column

D'0004_auto'

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect migration dependency.

Mixing up old and new field names.

Use the correct dependency migration and specify the old and new field names to rename a column safely.

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