Архив за [undefined]

Про не свой монастырь, но свой устав

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

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

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

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

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

Наследство с особенностями - 3

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

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

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

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

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

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

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

Наследство с особенностями - 2

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

  • Очередной сюрприз ждал меня, когда я обновляя свой блог-движок под текущий транк. Я обнаружил сломанным блок "Архив" из-за того, что метод 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. Потом этот id идет вверх по иерархии и затирает имеющиеся уже(загруженные из фиксчюры) значения. Похоже, что из-за этого ломается и CRUD.

    Так же это эффект проявляется когда вы просто хотите присоединить к уже имеющемуся базовому объекту какое-то дополнение в виде объекта ...