¿Qué son QuerySets y por qué son perezosos?

Question

Accepted Answer

Un **QuerySet** representa una colección de filas de base de datos como un objeto Python que puedes filtrar, ordenar y encadenar. Su característica definitoria es la **pereza** — un QuerySet **no** ejecuta una consulta a la base de datos cuando se crea; solo ejecuta la consulta cuando los datos realmente se necesitan (se evalúan). Entender esto es clave para escribir código Django eficiente.

## Por qué es importante

```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)
```

Construir y encadenar un QuerySet no cuesta nada — Django ensambla el SQL pero difiere la ejecución hasta que realmente necesites los resultados. Esto te permite componer consultas complejas de manera eficiente en un único viaje a la base de datos.

## Qué dispara la evaluación (un acceso a la base de datos)

```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()
```

## Por qué la pereza es poderosa

```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
```

La pereza te permite componer condicionalmente una consulta a lo largo de muchas líneas, luego ejecutarla **una vez** — eficiente y limpio.

## Caché de QuerySet

```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
```

Una vez evaluado, un QuerySet cachea sus resultados, por lo que reintentar el *mismo* QuerySet no vuelve a consultar la base de datos.

## La trampa de la pereza

```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: ...
```

## Por qué es importante

Entender QuerySets y su pereza es fundamental para escribir código Django de base de datos eficiente y correcto — afecta directamente el rendimiento y explica comportamientos que confunden a los principiantes.

La idea clave es que QuerySets **no acceden a la base de datos hasta ser evaluados**, lo cual es poderoso: puedes construir, filtrar, encadenar y componer condicionalmente consultas complejas a lo largo de muchas líneas de código sin costo de base de datos, luego ejecutar todo en un **único viaje** cuando realmente necesites los resultados.

Esto permite una construcción de consultas limpia y eficiente (por ejemplo, agregar condicionalmente filtros basados en la entrada del usuario, luego ejecutar una consulta) que de otro modo requeriría una construcción de cadenas SQL incómoda.

Saber precisamente **qué dispara la evaluación** (iteración, `len()`, `list()`, `.count()`, `.exists()`, etc.) y que los resultados están **en caché** en un QuerySet evaluado es esencial para evitar trampas comunes de rendimiento — más notablemente ejecutar accidentalmente la misma consulta varias veces (por ejemplo, llamar `.count()` y luego iterar un QuerySet fresco, accediendo a la base de datos dos veces).

La pereza es uno de los conceptos más importantes para usar bien el ORM de Django, separando a los desarrolladores que escriben código de base de datos eficiente de aquellos que disparan inconscientemente consultas redundantes, lo que la convierte en conocimiento central que subyace en todo el uso efectivo del ORM y la optimización del rendimiento en Django.