Некоторые особенности Django, о которых хорошо знать заранее

[@klinifini]

Наверное я слишком заранее начал читать статью. У меня пока в административном интерфейсе нет собственных действий.

[@zxmd]

Хорошая, годная статья. Автор молодца

[@Progrik]

По поводу действий в админке — да, там не всё так прозрачно как кажется.
Например, не вы не хотите юзать сигналы (signals), т.к. в них проблемно узнать был изменён объект или он новый (pre_save и проверка по pk — малость хак). Поэтому вы решили просто переопределить методы ModelAdmin (например, save_model и delete_model), но какова же будет ваша радость, когда вы узнайте, что код в методе delete_model, который вы в него написали будет срабатывать только когда вы удаляйте объект с его страницы редактирования (внизу кнопочка), а вот если выбрать кучу записей в админке и выбрать действие для удаления — этот метод не отработает, т.к. там всё удаление идёт через queryset.delete().

Я был сильно удивлён и раздосадован, когда столкнулся с этим, так как большинство сигналов уже было переписано, поэтому пришлось создать небольшой пакет, который исправляет эту хренотень: django-custom_delete_selected.

[@aruseni]

Да, а ещё, кстати, если вы добавляете в админку модель, таблица для которой находится в другой базе данных, то придётся писать так:

class MultiDBModelAdmin(admin.ModelAdmin):
    # A handy constant for the name of the alternate database.
    using = 'other'

    def save_model(self, request, obj, form, change):
        # Tell Django to save objects to the 'other' database.
        obj.save(using=self.using)

    def delete_model(self, request, obj):
        # Tell Django to delete objects from the 'other' database
        obj.delete(using=self.using)

    def queryset(self, request):
        # Tell Django to look for objects on the 'other' database.
        return super(MultiDBModelAdmin, self).queryset(request).using(self.using)

    def formfield_for_foreignkey(self, db_field, request=None, **kwargs):
        # Tell Django to populate ForeignKey widgets using a query
        # on the 'other' database.
        return super(MultiDBModelAdmin, self).formfield_for_foreignkey(db_field, request=request, using=self.using, **kwargs)

    def formfield_for_manytomany(self, db_field, request=None, **kwargs):
        # Tell Django to populate ManyToMany widgets using a query
        # on the 'other' database.
        return super(MultiDBModelAdmin, self).formfield_for_manytomany(db_field, request=request, using=self.using, **kwargs)

Ну, и вообще каждый раз, когда вы работаете с моделью через ORM, нужно указывать Model.objects.using('dbname'), а не просто Model.objects.

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

[@wpm1]

В post_save передается флаг created, а в pre_save — флаг add. Оба они почти всегда могут точно сказать, что объект создается впервые.

[@Progrik]

флаг? add? вы что-то путайте

[@wpm1]

да, точно, этот флаг передается в метод pre_save модели.

[@Fandal]

Полезная статья, добавил в закладки. Спасибо!

[@mrjj]

Formatters упоминается вскользь, так как логи построенны на стандартном Logging, какой смысл лишний раз разжевывать методики работы с ним?

[@wpm1]

стандартный jscatalog который идет с джангой — неудачное решение.

[@Progrik]

О чём вы? Какой ещё стандартный jscatalog?

[@wpm1]

Я про views.javascript_catalog

[@Progrik]

Ах вот вы о чём! Никогда, к счастью, не приходилось им пользоваться. Были другие пути решения таких задач :)

[@alTus]

Странно, а у меня нормально создается flatpage. Ну то есть выдается ошибка «Обязательное поле.» (django 1.4)

Правда оно у меня выдернуто из джанги и лежит как отдельное приложение, но там единственное изменение — это пара полей добавлено.

[@aruseni]

Полагаю, что дело именно в том, что оно у вас отдельно от Django. Если интересно, можете проверить соответствующий файл — может быть туда просто не попал тот коммит, который вызывает такую проблему. В тикете указывается этот коммит. А исправлено вот в этом.

[@michurin]

Ну про логи (пункт 2) — это вы зря. Джанга тут не причём, читайте просто питонскую документацию и все покровы спадут.
docs.python.org/howto/logging.html
docs.python.org/library/logging.html

[@stalkerg]

Вот по этому я и не использую Django. NIH он такой NIH…
Как пользовался Pylons так и буду дальше использовать. (или Tornado для чего то небольшого)