Django ORM Lens: N+1, Migration Safety & Schema Map

Verdict: BLOCK

Don't merge this as it stands. Migration 0002 renames Product.title to name in the database, but models.py still declares title. After migrate, every query that touches Product fails, and that includes the order history page. It also adds a NOT NULL column with no default, which fails on any table that already has rows.

Scope checked: branch pr vs master (1 changed file: catalog/migrations/0002_product_weight_and_index.py), 2 apps, 4 models, 3 migrations replayed, all 13 source files scanned. Templates are not in the repo, so I couldn't check them for references.

Good news: the PR does fix one earlier drift. Product.weight_grams was declared on master with no migration, and now it has one. It just needs a safe migration.

Safe rewrite of 0002

# catalog/migrations/0002_product_weight_grams.py
from django.db import migrations, models

def backfill_weight(apps, schema_editor):
    Product = apps.get_model("catalog", "Product")
    qs = Product.objects.filter(weight_grams__isnull=True)
    while True:
        ids = list(qs.values_list("pk", flat=True)[:1000])
        if not ids:
            break
        Product.objects.filter(pk__in=ids).update(weight_grams=0)

class Migration(migrations.Migration):
    dependencies = [("catalog", "0001_initial")]
    operations = [
        migrations.AddField(
            model_name="product",
            name="weight_grams",
            field=models.PositiveIntegerField(null=True, blank=True),
        ),
        migrations.RunPython(backfill_weight, migrations.RunPython.noop),
    ]

If you really want title called name, rename the Python attribute only. The column stays, so there's no data move and no rolling-deploy breakage:

# catalog/models.py
name = models.CharField(max_length=200, db_column="title")

# in the migration, state-only
migrations.SeparateDatabaseAndState(
    state_operations=[migrations.RenameField("product", "title", "name")],
    database_operations=[],
)

Update in the same commit (from impact title):

• catalog/serializers.py:9: "title" in ProductSerializer.Meta.fields (certain). Public API field: keep clients working with title = serializers.CharField(source="name").
• catalog/models.py:21: return self.title (likely)
• orders/views.py:13: item.product.title (likely)

If the index is needed, give it its own migration:

from django.contrib.postgres.operations import AddIndexConcurrently
from django.db import migrations, models

class Migration(migrations.Migration):
    atomic = False
    dependencies = [("catalog", "0002_product_weight_grams")]
    operations = [
        AddIndexConcurrently(
            "product",
            models.Index(fields=["is_active", "price"], name="product_active_price_idx"),
        ),
    ]

Still referenced

blast-radius looked up the new name name and reported 11 matches. I dismissed all of them: they are Category.name and name= keyword arguments in migrations, not Product. What actually breaks are the references to the old name title, listed above (1 certain, 2 likely).

---

Why the order history page is slow

orders/views.py:6 order_history is a nested N+1: one query for the orders, then for each order one query for items, and for each item one for product and one more for product.category.

Queries per request: 1 + N_orders + 2 x N_items. A customer with 20 orders of 3 items means

141 queries, growing with order history because the page isn't paginated.

Fix: one query

The page only renders item rows, so query OrderItem directly:

def order_history(request):
    items = (
        OrderItem.objects
        .filter(order__customer=request.user)
        .select_related("product__category")
        .order_by("-order__created_at", "order_id", "pk")
    )
    rows = [
        {
            "order": item.order_id,
            "product": item.product.title,
            "category": item.product.category.name,
            "qty": item.quantity,
        }
        for item in items
    ]
    return render(request, "orders/history.html", {"rows": rows})

141 queries down to 1. Re-ran the scan on a copy with the fix: 2 findings before, 0 after.

Also found by review: recent_orders (orders/views.py:20) loops over Order.objects.filter(status="paid")[:50] and reads order.customer.email, which is 50 extra queries, and the slice has no order_by, so "recent" means any 50 rows:

for order in (Order.objects.filter(status="paid")
              .select_related("customer")
              .order_by("-created_at")[:50]):

Pin it with a test

def test_order_history_query_count(client, django_assert_num_queries, customer_with_orders):
    client.force_login(customer_with_orders)
    with django_assert_num_queries(3):  # session + user + the one OrderItem query
        client.get("/orders/history/")

Next steps (deploy order)

This PR. Take the RenameField out of 0002 (or switch to db_column / SeparateDatabaseAndState and update the serializer, __str__ and orders/views.py:13 in the same commit). Make weight_grams nullable with a backfill. Move the index to its own concurrent migration and declare it in Meta.indexes, or drop it.
2. Re-run the review: blast-radius --severity all --only <new migrations> and drift. Expect 0 critical and no blocking drift for catalog.
3. Separate PR. Fix order_history and recent_orders, add the query-count test.
4. Separate PR. Sort out the OrderItem.unit_price drift after checking the production schema.
5. Next release. Enforce NOT NULL on weight_grams once the backfill has run everywhere.