Django & DRF Mastery: Build Robust Web Apps & APIs from Scratch

Your Database: A Living, Breathing Structure

You've built your Django models, and they define the structure of your database tables. But what happens when your application grows and your requirements change? You might need to add a new field to a model, introduce a completely new model (and thus a new table), or even remove an old one.

Manually making these changes to your database using SQL commands is tedious, error-prone, and can quickly lead to inconsistencies, especially when working in a team or deploying to multiple environments (development, staging, production). Imagine forgetting to add a column on the production server!

This is precisely the problem Django's powerful Migrations system solves. It's like a version control system (think Git!) for your database schema, allowing you to manage changes to your models in a structured, consistent, and reversible way. At UdaanPath.com, we emphasize robust development practices, and migrations are fundamental to stable application growth.

Key Migration Commands in Action

1. `makemigrations [app_name]`

Detects changes in your models and creates new migration files. If no `app_name` is provided, it checks all apps.

**Scenario: Adding a new field to `Post` model.** First, modify `blog/models.py`:

# blog/models.py
from django.db import models
# ... other imports

class Post(models.Model):
    # ... existing fields ...
    title = models.CharField(max_length=200)
    content = models.TextField()
    pub_date = models.DateTimeField(auto_now_add=True)
    updated_date = models.DateTimeField(auto_now=True)
    author = models.ForeignKey('Author', on_delete=models.CASCADE)
    tags = models.ManyToManyField('Tag')
    
    # NEW FIELD ADDED HERE:
    is_published = models.BooleanField(default=False) # Added a boolean field

    def __str__(self):
        return self.title
            

Now, run `makemigrations`:

# In your terminal, in the project root:
python manage.py makemigrations blog
            

Expected Output:

Migrations for 'blog':
  blog/migrations/000X_add_is_published_to_post.py
    - Add field is_published to post
            

A new Python file (e.g., `000X_add_is_published_to_post.py`) will be created in your `blog/migrations/` directory. This file contains the instructions for Django to add the `is_published` column to your `Post` table. **Do not manually edit these files unless you absolutely know what you're doing!**

2. `migrate [app_name] [migration_name]`

Applies the pending migrations to your database.

# In your terminal:
python manage.py migrate blog
            

Expected Output:

Operations to perform:
  Apply all migrations: blog
Running migrations:
  Applying blog.000X_add_is_published_to_post... OK
            

Your database table for `Post` now has the new `is_published` column!

3. `showmigrations [app_name]`

Shows the status of all migrations (applied or not applied) for your project or a specific app.

# In your terminal:
python manage.py showmigrations blog
            

[X] 0001_initial [X] 0002_userprofile [X] 000X_add_is_published_to_post (...)

An `[X]` means the migration has been applied.

4. `sqlmigrate app_name migration_name`

Shows the raw SQL that Django would execute for a given migration. Useful for understanding what's happening under the hood or for database administrators.

# In your terminal (replace 000X with your migration number):
python manage.py sqlmigrate blog 000X_add_is_published_to_post
            

BEGIN; -- -- Add field is_published to post -- ALTER TABLE "blog_post" ADD COLUMN "is_published" bool NOT NULL DEFAULT false; COMMIT;

This shows the SQL statement Django generates for your specific database (e.g., PostgreSQL, MySQL, SQLite).

Common Schema Changes and Django's Handling

• Adding a new model: Django creates a new table.
• Adding a new field: Django adds a new column. If the field is non-nullable (`null=False`) and there's existing data, Django will prompt you for a one-off default value or to make it nullable temporarily.
• Modifying a field: Django alters the column (e.g., changes `max_length`, adds `null=True`).
• Renaming a field: Django detects this and generates a `RenameField` operation.
• Deleting a field: Django generates a `RemoveField` operation, but it will ask for confirmation because this is a destructive action (data will be lost!).
• Deleting a model: Django generates a `DeleteModel` operation, also destructive.

Key Takeaways & Best Practices

• Always use Django Migrations to manage all changes to your database schema. Never modify your database directly via SQL unless you are an advanced user with a specific reason.
• The core workflow is: **Modify `models.py` → `makemigrations` → `migrate`**.
• `makemigrations` creates the instructions; `migrate` executes them.
• **Commit your migration files to version control!** They are a crucial part of your project's history, just like your code.
• Avoid manually editing migration files unless absolutely necessary and you understand the implications.
• **Interview Prep:** Be ready to explain the purpose of migrations, the difference between `makemigrations` and `migrate`, and how to handle common scenarios like adding a non-nullable field to an existing table.