Note: There is a english version of this post here: Django Tip: Modify the generated SQL statement of a queryset

El método extra de los queryset nos permite realizar algunas modificaciones en las sentencias sql que ejecuta. En concreto nos permite añadir campos a la cláusula SELECT, o tablas y joins a la cláusula FROM, o condiciones a la cláusula ORDER BY.

Supongamos, por ejemplo, que tenemos una tabla de productos a la venta, algo como esto:

class Item(Model):
    id = AutoField(primary_key=True)  # Me gusta especificar la clave
    descripcion = CharField(max_length=200)
    pvp = DecimalField(max_digits=12, decimal_places=2)
    alta = DateTimeField(auto_now_add=True)

Podemos añadir un campo calculado que nos indique si los precios son inferiores a 5.0 (quizá queremos marcar estos productos en la página con un icono de "low-price", por ejemplo). Para ello, podemos añadir un campo calculado al select de la query usando extra, como en el siguiente ejemplo:

Item.objects.extra(select={'low_price':'pvp < 5.0'}).all()

Lo que estamos haciendo es que la sentencia SQL generada por Django pase de esto:

SELECT app_item.*
  FROM app_item;

a esto:

SELECT app_item.*, (pvp < 5.0) AS low_price
  FROM app_item;

Podemos pasar varios campos calculados en el diccionario especificado por el parámetro select, o hacer varias llamadas a extra. Por ejemplo, si queremos clasificar los precios en tres bandas, (baratos, por debajo de 5 euros; medios, entre 5 y 100 euros y caros, por encima de 100 euros), podemos hacerlos así:

Item.objects.extra(select={
    'low_price':'pvp < 5.0',
    'mid_price':'pvp between 5.0 and 100.0',
    'low_price':'pvp > 100.0',
    }).all()

O así:

Item.objects  \
    .extra(select={'low_price':'pvp < 5.0'})  \
    .extra(select={'mid_price':'pvp between 5.0 and 100.0'}) \
    .extra(select={'low_price':'pvp > 100.0'})  \
    .all()

El resultado debería ser el mismo en los dos casos.

Es verdad que podemos realizar este calculo de bandas de precios en un simple método de la clase Item, pero en ocasiones puede sernos útil o necesario que determinadas operaciones las haga la base de datos por nosotros.

Obviamente también podemos pasar subconsultas como campo añadido al select, que nos da aun más posibilidades. Por ejemplo, supongamos que en nuestra aplicación tiene otro modelo con las puntuaciones que nuestros clientes asignan a nuestros artículos, algo como esto:

class Score(models.Model):
    id = AutoField(primary_key=True)  # Si, ya lo sé, no hace falta...
    item = ForeignKey(Item)
    rate = SmallIntegerField()

Podemos realizar una consulta sobre artículos e incorporar la puntuación media de cada uno, calculada directamente por el gestor de la base de datos:

Item.objects.extra(select={
    'mean_rate':'''
        SELECT AVG(app_score.rate)
          FROM app_score
         WHERE app_score.item_id = app_item.id
         '''
    }).all()

Si quisiéramos hacerlo desde Django, con un método de la clase Item, por ejemplo, tendríamos que realizar primero una consulta para obtener todas las puntuaciones de un artículo, y luego calcular la media.

Si lo hacemos para una consulta cuyo resultado final fueran 10 artículos, por ejemplo, tendríamos que hemos realizado 11 consultas SQL a la base de datos, haciendo además el cálculo nosotros, por una sola consulta, si los cálculos los realiza el SGBD. La diferencia en rendimiento puede ser considerable.

Estás prácticas también tienen su lado peligroso: hemos vinculado más nuestro código al gestor de base de datos que estamos usando, con las dependencias y peligro que eso conlleva. Si usamos extensiones propietarias de la base de datos para realizar la consulta, aunque sea algo tan simple como utilizar la marca de tiempo de la base de datos (Que cada gestor se empeña en definir de forma diferente, sysdate en Oracle, now() en postgreSQL, current_timestamp en Microsoft SQL Server, por citar solo unos pocos ejemplos), ya tenemos un punto de ruptura si pretendemos migrar de gestor.

En cualquier caso, es útil saber que tenemos esta capacidad, ya depende de nosotros si queremos emplearla o no. Recuerda solo estos tres consejos:

• Explícito mejor que implícito (Tim Peters)
• Los casos especiales no son tan especiales como para romper las reglas ... pero lo práctico vence a lo ideal (Tim Peters)
• Todo gran poder conlleva una gran responsabilidad (Benjamin Parker)

Nota: El uso de extra para modificar las cláusulas FROM y WHERE está explicado, junto con muchas otras cosas interesantes, en la documentación oficial: Django Query Set API reference - extra.