Выражения в джанговских запросах

Сегодня был опубликован план на следующий релиз Джанго 1.1. В нем много всякого хорошего, но мое внимание привлекла красота реализации одной из must-have фич, и я решил поделиться с вами неожиданно нахлынувшей на меня радостью :-). Заодно кто-то, как я, узнает новую для себя возможность Питона.

Речь идет о тикете 7210 — "Added expression support for QuerySet.update". Это про то, что сейчас джанговский ORM не умеет создавать SQL для условий в запросах, в которых есть а) выражения:

update page set views_count = views_count + 1 where id = 123;

б) поля в качестве значений:

select * from employee where current_salary > start_salary;

Теперь это можно будет делать.

Загвоздка

Но самое интересное — это синтаксис, которым такие штуки записываются. В нем, собственно, и была главная загвоздка, почему этой фичи не было в ORM еще давно. Действительно, если написать все как есть, то получится:

# вместо увеличения на единицу текущего значения Питон увеличит локальну переменную 
# views_count, которой еще и нет наверняка
Page.objects.filter(pk=123).update(views_count=views_count + 1)

# вместо поля start_salary будет использована строка "start_salary", которая свалится
# на приведении к числу
Employee.objects.filter(current_salary__gt='start_salary')

F-объект

Проблему решили введением специального объекта, который означает "поле в этом запросе". И назвали его, что важно, кратко — F. В итоге оба примера начинают выглядеть вот так:

Page.objects.filter(pk=123).update(views_count=F('views_count') + 1)
Employee.objects.filter(current_salary__gt=F('start_salary'))

Кода придет время формировать SQL, объект запроса будет знать, что F-объект содержит в себе название поля. С вытекающим отсюда правильным экранированием и т.д.

Минуточку...

Раз F — объект для отложенного хранения имени поля, то как работает конструкция F('views_count') + 1? Оказывается, F переопределяет для себя все имеющие смысл математические операции методами __add__, __sub__, __mul__ и прочими, которые Питон использует при рассчете выражений. Результатом каждой из них является такой же объект F, который хранит у себя свои операнды. Соответственно, эти вызовы можно комбинировать (хотя практического юзкейса я еще не придумал):

op = F('field') + 1   →  op = F('field').__add__(1)
op2 = op * 3          →  op2 = op.__mul__(3)

А вот на закуску стоит сказать, что эти вещи работают и при переставленных операндах. То есть:

1 + F('field')

... не свалится, хотя у объекта int и не определено, как к нему __add__ джанговский F-объект. Вот эта магия достигается за счет обратных методов операций: __radd__, __rmul__ и т.д. Они вызываются у правого объекта в операции, если вызов прямого метода на левом объекте выдал ошибку NotImplemented. Соответственно:

1 + F('field')        →  F('field').__radd__(1)

Я даже, пожалуй, скажу, что такой простой двухступенчатый алгоритм нравится мне больше, чем дико сложная штука в C++, где выражение x + y будет пытаться найти все возможные преобразования типов операндов, позволяющих выполнить операцию.