Довелось поучаствовать в очень интересной, на мой взгляд, дискуссии. Так вот, как мне кажется человек не с той стороны подходит к джанго и к 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
Сериализатор дампит модель наследника целиком, т.е. со всеми полями в том числе и родителей.
При загрузке модели родителей не могут подцепить свой первичный ключ, а просто делают новый INSERT, получая тем самым новый id. Потом этот id идет вверх по иерархии и затирает имеющиеся уже(загруженные из фиксчюры) значения. Похоже, что из-за этого ломается и CRUD.
Так же это эффект проявляется когда вы просто хотите присоединить к уже имеющемуся базовому объекту какое-то дополнение в виде объекта ...