Давно уже перестало быть секретом, что Django-ORM в целом глупое как палка и не способно решать более менее серьезные задачи, и особо глупа в тех случаях, когда необходимо влиять извне на формирование разумных SQL запросов. Об одном из таких случаев и как я пытался с этим бороться — поведаю под катом.
Все началось с того, что ковыряние базы TecDoc навеяло мне идею реализовать свою систему хранения переводов в бд. Не долго думая я накидал такие модельки для приложения переводов и одну для издевательства:
class Translations(models.Model):
" переводы "
text = models.TextField(null=True, blank=True)
lng = models.SlugField(max_length=32, choices=settings.LANGUAGES, db_index=True)
des = models.ForeignKey("Designations", db_index=True, related_name='translations')
class Meta:
verbose_name = _("translation")
verbose_name_plural = _("translations")
ordering = ['lng']
# db_table='mlang_translations'
class Designations(models.Model):
" описание (метка) перевода содержит только поле id"
class Meta:
verbose_name = _("designation")
verbose_name_plural = _("designations")
# db_table='mlang_designations'
class Page(MPTTModel):
content = models.ForeignKey('mlang.Designations', null=True, blank=True, related_name="+")
keywords = models.ForeignKey('mlang.Designations', null=True, blank=True, related_name="+")
description = models.ForeignKey('mlang.Designations', null=True, blank=True, related_name="+")
title = models.ForeignKey('mlang.Designations', null=True, blank=True, related_name="+")
code = models.CharField(max_length=256, db_index=True)
parent = TreeForeignKey('self', null=True, blank=True)
# db_table='flatpages_page'
Работает это следующим образом:
Множество моделей ссылаются на метки переводов после чего можно получить перевод для поля на один из языков. Количество запросов в самом простом случае будет 1 + количество полей, которые надо перевести * количество объектов в выборке
Как видно из описания моделей переводимые поля и сами переводы ссылаются на одну и ту же метку, что позволяет с легкостью форсировать саму метку при выборке переводов за счет прямого JOIN'а перевода к нужному полю. И вот тут то и начинаются пляски с бубном.
Начнем пожалуй с варианта «в лоб», который лучше не использовать, если других вариантов не существует: QuerySet.raw и получаем такой код:
Page.objects.raw("""
select
fpage.id id,
content_translated.text content_translated,
title_translated.text title_translated,
keywords_translated.text keywords_translated,
description_translated.text description_translated
from flatpages_page fpage
left join mlang_translations content_translated on fpage.content_id=content_translated.des_id and content_translated.lng=%s
left join mlang_translations description_translated on fpage.description_id=description_translated.des_id and description_translated.lng=%s
left join mlang_translations keywords_translated on fpage.keywords_id=keywords_translated.des_id and keywords_translated.lng=%s
left join mlang_translations title_translated on fpage.title_id=title_translated.des_id and title_translated.lng=%s
""", params=["ru", "ru", "ru", "ru"])
плюсы и минусы данного подхода расписывать думаю не надо.
естественно, если моделей много и/или надо получать переводы в нескольких вьюхах, и/или поля изменятся в какой-то момент — это будет кошмаром на яву.
начинаем активно гуглить на тему django orm left join дабы получить эквивалетный SQL запрос, но python/django way.
первое, что мне попалось на глаза — это подделать Q объект, так чтобы он превратился в LEFT JOIN: QLeftOuterJoin, а если погуглить подольше и внимательнее можно заметить, что данное решение древнее как мамонты и примерно с 2010го года оно не работает. Попытки запустить успехом не увенчались.
потом в выдаче гугла встречаем некий "хак" из коробки над QuerySet.query, который стандартными средствами позволяет вшить кастомный INNER/LEFT JOIN в QuerySet и для нашей экспериментальной выборки код будет выглядеть вот так:
qs = Page.objects.filter(id__isnull=False) # костыль, иначе дальше не работает.
for field in Page._meta.local_fields:
if field.rel is not None and field.rel.to is Designations:
join = qs.query.join(
(Page._meta.db_table, Translations._meta.db_table, ((field.name+'_id', 'des_id'),)),
nullable=True, # это LEFT JOIN
join_field=Translations._meta.get_field_by_name('des')[0]
)
qs = qs.extra(
select={
field.name+"_translated": join+'.text'
},
where=[join+".lng=%s"],
params=['ru']
)
Расскажу, что тут происходит: перебираем все поля модели Page и для каждого ForeignKey(Designations) генерим уникальный JOIN. В docstring query.join написано:
'join_cols' is a tuple of tuples containing columns to join on ((l_id1, r_id1), (l_id2, r_id2))
Т.е. 3-м элементом первого агрумента мы можем передать множество связывающих полей для условия, НО не можем сделать фильтрацию в пределах JOIN'a. В следствии чего в вызове qs.extra появились where и param, что в свою очередеть весь наш LEFT JOIN сломали в обычный INNER JOIN вида:
SELECT ... FROM
flatpages_pages, mlang_translations t1, mlang_translations_t2, .....
where
t1.lng='ru' AND t2.lng='ru' AND ......
С одной стороны можно сказать — это фича, если одно поле не переведено значит скрываем всю запись и отдаем 404ю. С другой стороны это совсем не то поведение, которое мне хочется по умолчанию.
Ну да ладно, идем дальше нормальным django way, описанном в документации: QuerySet.extra и напишем такую вспомогательную функцию для автоматической генерации переводов к нужной модели:
def translate(model, lng, exclude=None):
if exclude is not None and not isinstance(exclude, (list, tuple, set, frozenset,)):
raise TypeError('exclude must be iterable')
fields = []
for field in model._meta.fields:
if field.rel is not None and field.rel.to is Designations:
if exclude is not None and field.name in exclude:
continue
fields.append(
[field.name, map(lambda x: x[1], field.rel.get_joining_columns())[0]]
)
if not fields:
return {}
return dict(
tables=[
'"{trans._meta.db_table}" AS "trans_{pos}"'.format(trans=Translations, pos=pos)
for pos, val in enumerate(fields)
],
select={
column[0] + "_translated": "trans_{0}.text".format(pos)
for pos, column in enumerate(fields)
},
where=[
"{model._meta.db_table}.{column[1]}=trans_{pos}.des_id and trans_{pos}.lng=%s".format(pos=pos,
column=column,
model=model)
for pos, column in enumerate(fields)
],
params=[lng] * len(fields)
)
Работает она довольно просто: перебирает все ForeignKey(Designations) из переданной модели и заполняет словарь для передачи в QuerySet.extra в итоге получается такой вызов:
Page.objects.extra(**translate(Page, lng))
Смотрится красиво, НО это те же яйца только в профиль, что и в п2, только не генерируя LEFT JOIN в тексте запроса…
Итого: за ~12 часов активного гуглинга и курения исходников, истина по прежнему где-то там, а пока п3 берем в разработку как фичу и продолжаем искать возможность по уму научить джангу сторить умные запросы.
Исходники проекта можно пощупать тут.
P.S: На днях дополню статью, если появятся новые варианты в поисках ответов.
Автор: Magikan
