Wat zijn QuerySets en hoe werken ze lazy?

Question

Accepted Answer

Een **QuerySet** vertegenwoordigt een verzameling databaserijen als Python-object dat je kunt filteren, sorteren en koppelen. Het definiërende kenmerk is **laziness** — een QuerySet raakt **niet** de database wanneer het wordt aangemaakt; het voert de query alleen uit wanneer de gegevens daadwerkelijk nodig zijn (geëvalueerd). Dit begrijpen is essentieel voor het schrijven van efficiënte Django-code.

## QuerySets zijn lazy — geen database hit totdat geëvalueerd

```python
# NONE of these touch the database — they just build up the query
qs = Article.objects.all()                  # no query yet
qs = qs.filter(published=True)              # still no query — chaining is lazy
qs = qs.exclude(views=0).order_by("-created_at")   # still no query

# the database is hit ONLY when the QuerySet is EVALUATED:
for article in qs:        # ← NOW the query runs
    print(article.title)
```

Het bouwen en koppelen van een QuerySet kost niets — Django assembleert de SQL maar stelt de uitvoering uit totdat je de resultaten daadwerkelijk nodig hebt. Dit stelt je in staat complexe queries efficiënt in één databasetocht samen te stellen.

## Wat evalutatie triggert (een database hit)

```text
✓ Iterating:        for x in qs
✓ Slicing with step: qs[::2]  (plain slicing qs[:10] stays lazy, adds LIMIT)
✓ len(qs), list(qs), bool(qs)
✓ Calling a non-QuerySet method: .count(), .exists(), .first(), .get(), .aggregate()
```

## Waarom laziness krachtig is

```python
# build a query conditionally WITHOUT extra database trips
qs = Article.objects.all()
if search:
    qs = qs.filter(title__icontains=search)   # no DB hit
if category:
    qs = qs.filter(category=category)          # no DB hit
articles = qs[:20]                              # ONE query runs here, with LIMIT 20
```

Laziness stelt je in staat een query voorwaardelijk over veel regels samen te stellen en vervolgens **eenmaal** uit te voeren — efficiënt en schoon.

## QuerySet caching

```python
qs = Article.objects.filter(published=True)
list(qs)     # query runs, results CACHED on the QuerySet
list(qs)     # uses the CACHE — no second query
# BUT a NEW queryset re-queries:
Article.objects.filter(published=True)   # a fresh queryset → new query
```

Eenmaal geëvalueerd, cacht een QuerySet zijn resultaten, dus het opnieuw itereren over *dezelfde* QuerySet voert geen hernieuwde query uit.

## Het laziness pitfall

```python
# ⚠️ calling .count() then iterating runs TWO queries
if Article.objects.filter(published=True).count() > 0:   # query 1
    for a in Article.objects.filter(published=True):     # query 2 (new queryset!)
        ...
# ✅ better — evaluate once, reuse
qs = list(Article.objects.filter(published=True))
if qs: ...
```

## Waarom het belangrijk is

Het begrijpen van QuerySets en hun laziness is fundamenteel voor het schrijven van efficiënte, correcte Django-databasecode — het beïnvloedt rechtstreeks de prestaties en verklaart gedragingen die beginners verwarren.

De sleutelinsight is dat QuerySets **niet de database raken totdat geëvalueerd**, wat krachtig is: je kunt over veel regels code complexe queries bouwen, filteren, koppelen en voorwaardelijk samenstellen zonder databasekosten, en vervolgens alles in één **enkele tocht** uitvoeren wanneer je de resultaten daadwerkelijk nodig hebt.

Dit maakt schone, efficiënte query-constructie mogelijk (bijv. voorwaardelijk filters toevoegen op basis van gebruikersinvoer en vervolgens één query uitvoeren) die anders onhandige SQL-stringbouwing zou vereisen.

Precies weten **wat evalutatie triggert** (iteratie, `len()`, `list()`, `.count()`, `.exists()`, enzovoort) en dat resultaten **cached** zijn op een geëvalueerde QuerySet is essentieel om veelvoorkomende prestatieproblemen te voorkomen — vooral het accidenteel meerdere keren dezelfde query uitvoeren (bijv. `.count()` aanroepen en vervolgens een frisse QuerySet herhalen, twee keer de database raken).

Laziness is een van de belangrijkste concepten voor goed Django ORM-gebruik, onderscheidend ontwikkelaars die efficiënte databasecode schrijven van degenen die onbewust redundante queries triggeren, waardoor het kernkennis is die al effectief ORM-gebruik en prestatie-optimalisatie in Django onderbouwt.