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

Довелось поучаствовать в очень интересной, на мой взгляд, дискуссии. Так вот, как мне кажется человек не с той стороны подходит к джанго и к agile технике как таковой.

Нет. я не отрицаю этап моделирования или проектирования. Они безусловно нужны. И теоретики agile подхода на этом делают акцент. Но не надо возводить их в ранг первостепенных и основных этапов разработки.

Имея настолько гибкие инструменты как динамические языки программирования (питон), и фреймворки (джанго), можно и моделировать, и проектировать используя их. Тот DSL который предоставляет джанго для описания моделей, на мой взгляд, настолько нагляден и даже визуален, что заменять его диаграммами, и уж тем более ставить их во главу угла нельзя. Написанная модель это не только некая мета информация, но уже готовый функционал, который можно подергать через shell и прикинуть варианты использования. Всё это сразу. Без сугубо теоретических рисований диаграмм и их перетаскивания их одного угла в другой.

Диаграммы конечно же нужны. Но потом. Либо в момент написания некой вспомогательной документации, либо просто ...

Читать далее

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

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

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

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

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

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

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

Читать далее

Я всё продолжаю по рабочим и не только нуждам ковырять наследование моделей, поэтому как и обещал - то ли ещё есть!

• Очередной сюрприз ждал меня, когда я обновляя свой блог-движок под текущий транк. Я обнаружил сломанным блок "Архив" из-за того, что метод dates() перестал возвращать уникальные значения на месяца, а выдавал мне всё подряд. Я сильно удивился. Но пофиксил всё при помощи, в последнее время моего любимого, set. Да, костыль, но ковырять дальше пока желания нет.

• Далее уже по рабочим нуждам обновления тест наборы для приложения, проявились некоторые особенности работы fixtures. Для примера, допустим у нас есть такие связанные наследованием модели:

  class Base( models.Model ):
     field1 = models.IntegerField( default = 10 )
     # + неявное поле id
  
  class Derived( Base ):
     field2 = models.IntegerField( default = 1 )
     # + неявное поле base_ptr
  

  1. Сериализатор дампит модель наследника целиком, т.е. со всеми полями в том числе и родителей.

  2. При загрузке модели родителей не могут подцепить свой первичный ключ, а просто делают новый INSERT, получая тем самым новый id. Потом этот ...

Читать далее

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

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

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

  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 запросы. Которые после недавних событий стали гораздо валиднее и краше. Класс!

Только ...

Читать далее