Интернет нового века

Да, транк живой и в нем продолжаются интересные изменения, связанные с отладкой всей системы после qsrf. Ну и продолжается мой сериал про них. С содержанием предыдущих серий вы можете ознакомиться здесь и здесь. Приступим.

• После ченджсета #7600 изменилось поведение сохранения объекта с явным указанием предка. Т.е. теперь трюк выглядит более логично на мой взгляд:

  base = Base.objects.create( field1 = 777 )
  d = Derived( base_ptr = base )
  d.save_base( raw = True )
  

  Теперь при явном вызове save_base с raw=True создания нового предка не происходит, а используется уже имеющийся. Да всё равно коряво немного, но поскольку изначально это был не то чтобы баг, а просто некая особенность, то требовать чего-то больше наверно уже не надо.

• При загрузке создании фиксчюресов теперь сохраняются только поля данной модели. Что выглядит действительно более логично. А при загрузке, с учетом предыдущего пункта, загрузка происходит вполне нормально.

  Неудобно что надо переписывать тестовые фиксчюресы:)

Держу руку на пульсе.

Читать далее

И так, некоторые время назад состоялось моё погружение в новый для джанго мир наследования моделей. Как и в моих домашних проектах и так и в рабочих. Исследованию подверглось мульти-табличное наследование. Среди достаточного количества удобных и полезных свойств наследования преподнесло несколько неожиданностей и даже ошибок, которые были обнаружены в механизме самой джанги.

Начнем с особенностей:

• Кастомные менеджеры наследуются. Что вполне логично, если учесть, что менеджер это всего-лишь обычное поле класса, которое при наследовании переходит к наследнику. Но, что не очень очевидно на первый взгляд, так то, что он остается "прикрепленным" к модели предка и его использование с моделью наследника будет давать не совсем ожидаемы результат. Вот пример:

  class Base( models.Model ):
     field1 = models.IntegerField()
  
     objects = models.Manager()
     my_custom_manager = MyManager()
  
  class Derived( Base ):
     field2 = models.IntegerField()
  
  #...
  
  Derived.my_custom_manager.filter( field2 = 777 )# Вот это не сработает
  # и ругнется на отсутсвие данного поля у Base модели, что есть правда
  

  Отсюда вывод - переопределяйте свои менеджеры в моделях наследниках. Вот соответствующее обсуждение в джанго-девелоперс

• Теперь немного ...

Читать далее

В очередной раз разгребая от непомерного груза непрочитанных RSS свой ридер, наткнулся на примечательный пост некого Энди Маккея (кстати блог у него на джанге. Узнал случайно - получив от него как-то стандартный джанговский 404:)).

Суть в том, что он применяет джангу в качестве базы для прототипирования Zope приложений. Поскольку как вы сами прекрасно понимаете, на джанго быстрее и проще сделать что-работающее. Использует все вкусности ORM и CRUD'а для добавления тестовых данных. Потом набивает тесты с необходимым функционалом и "ворует" у ORM сгенерированные SQL запросы, портируя их в ZSQLMethods(это такая зопавская(вау!:)) обертка над SQL запросами). Да, зачем мучит себя ручным написанием мудреных запросов, когда можно поручить это машине, а самому кайфовать от высокоуровневых абстракций. Не правда ли элегантное и остороумное решение?:)

И действительно. Ведь так удобно: быстренька набросать модельки, попутно ещё и DDL получить бесплатно, потом набить всё это необходимой логикой и получит у любезного ORM SQL запросы. Которые после недавних событий стали гораздо валиднее и краше. Класс!

Только ...

Читать далее

Наконец-то! Уверен, что я не один воскликнул это слово, когда узнал что долгожданная queryset-refactor ветка влилась в транк и теперь ORM в джанго стал ещё лучше и удобней! Этого момента ждали долга, поскольку это один из самых больших шагов по направлению к 1.0 версии джанги. Итак, что же мы получили.

Начну с основных изменения уже имеющегося функционала:

• Указание сортировки по при-join-ненным моделям теперь стало более логичным и совпадает с фильтрами lookup'ов. Просто пример:

  Order.objects.all().order_by( "product__price" )
  

• Обновлена реализация __iter__ метода queryset'a. И не грузит все строки результат в память сразу.

• Особенно меня радует: сделана нормальная обработка None значения в lookup'ах. Т.е. если раньше приходилось писать писать воркэраунды для случая когда селект осуществлялся по NULL значениям, например так:

  if value is None:
      queryset = queryset.filter( field__isnull = True )
  else:
      queryset = queryset.filter( field = value )
  

  То теперь эта проверка лишняя не нужна. Ура!)

• Есть ещё некоторое количество изменений, но они на низко уровне и на прямую ...

Читать далее

Уже давно известно о небольшой(?) проблеме, связанной с post_save сигналом и ManyToMany отношением моделей. Для примера, Лориен столкнулся некоторое время назад с ней, о чем есть интересный тред на форуме.

Я же всё как-то раньше мимо проходил этой особенности, но тут столкнулся лицом к лицу. Кратко расскажу предысторию.

В процессе уменьшения TODO листа по улучшению блога, встала задача организации оповещения по почте о новых комментариях. Но делать реализацию жестко завязанную на блоге не хотелось, поскольку задача оповещения в принципе может встать в любом приложении. Поэтому некоторое время я пытался разработать, до некоторой степени, универсальную систему оповещений, легко интегрируемую в любое приложение. Одной из особенностей этой системы была завязка на джанго сигналах. Уж больно направилась такая связь: произошло некоторые событие -> образовался сигнал -> пошло оповещение нужным пользователям.

И когда черновой вариант системы был реализован, я сразу решил бросить ей в бой. Первый вариант не сработал. Повесить оповещение на post_save сигнал у модели Comment не получилось. Точнее получилось конечно, но не был достигнут ...

Читать далее