Django ORM Fundamentals

What we're doing: Build a filtered QuerySet across two chained calls, confirming that the second call does not mutate what the first would still return.

q1 = Entry.objects.filter(headline__startswith="What")
q2 = q1.exclude(pub_date__gte=today)

list(q1)   # entries starting with "What" — q1 was never touched by building q2
list(q2)   # the same starting entries, minus anything published today or later

1

q1 is a QuerySet object, not a result — no SQL has run yet.

2

q1.exclude(...) clones q1 and adds one more clause, returning a NEW QuerySet (q2) — q1 itself is completely unaffected by this call.

4

Evaluating q1 here confirms it still behaves as if q2 had never been built — proof that chaining clones rather than mutates.

Why this works: If exclude() mutated q1 in place instead of cloning it, building q2 from q1 would silently change what q1 itself returns later — a bug that would be very hard to trace, since nothing about the call q1.exclude(...) looks like it should affect q1. Cloning is what makes a single base QuerySet safely reusable as the starting point for several different, independent refinements.

What we're doing: Check whether any pending orders exist without loading them, then separately fetch exactly one order by its unique reference, handling the not-found case explicitly.

def has_pending_orders(customer):
    return Order.objects.filter(customer=customer, status="PENDING").exists()

def get_order_or_404_message(reference):
    try:
        return Order.objects.get(reference=reference)
    except Order.DoesNotExist:
        return None

2

exists() answers "is there at least one?" without ever loading a single Order into memory — cheaper than .count() > 0 (which counts every match) and much cheaper than list(...) (which loads every full row).

6

get() is correct here because reference is meant to be unique — MultipleObjectsReturned would itself indicate a real data-integrity bug worth surfacing loudly, not something to silently paper over.

Why this works: exists() and count() are both real queries, but neither transfers actual row data over the wire the way iterating a QuerySet or calling list() does — reaching for .exists() instead of bool(queryset) or len(list(queryset)) avoids loading data the caller was never going to use anyway.

What we're doing: Use update_or_create() to either create a customer's loyalty record or refresh its points total, in one call, distinguishing lookup fields from fields only set on write.

def sync_loyalty_points(customer, points):
    record, created = LoyaltyAccount.objects.update_or_create(
        customer=customer,
        defaults={"points": points, "last_synced_at": timezone.now()},
    )
    return record, created

2

customer=customer is the LOOKUP — it identifies which row this is about, and is also set on the row if one is created.

3

defaults={...} are the fields written EITHER WAY — set on a fresh row if none existed, or overwritten on the existing row if one did. Fields outside defaults are used only for the lookup, never touched on update.

Why this works: Writing this as a manual try/get/except/create would need roughly the same number of lines but without the transaction wrapping update_or_create() provides internally — and would be easy to get subtly wrong (e.g. forgetting to also handle the update path when the object already exists, which update_or_create() guarantees by design).