Cantos escuros do auto_now_add do Django

Há uma declaração de modelo em um de nossos projetos existentes,

class Event(models.Model):
    name = models.CharField(max_length=20)
    created_at = models.DateTimeField(auto_now_add=True)

Usamos auto_now_addpara especificar o tempo criado automaticamente. Quando o modelo de evento é usado cada vez mais, às vezes temos cenários que created_atnão são iguais ao tempo criado da instância do modelo.

event = Event(name='new event')
# today is 2013-08-24
event.created_at = datetime.datetime(2013, 8, 10)
event.save()
>>> event.created_at
datetime.datetime(2013, 8, 24, 14, 10, 11, 181193)

Não é esperado, mas os documentos do django explicam a regra :

Note that the current date is always used; it’s not just a default value that you can override.

Quando você quiser definir a data e hora como quiser, basta salvar novamente,

event.created_at = datetime.datetime(2013, 8, 10)
event.save()

Em seguida, adiciono um valor padrão de campo para substituir auto_now_add:

import datetime

class Event(models.Model):
    name = models.CharField(max_length=20)
    created_at = models.DateTimeField(default=datetime.datetime.now)

Mas isso não é completamente o mesmo efeito que auto_now_add, um CreateView of Event baseado em classe se envolve em um erro de validação de formulário. created_at is neededPara resolver este problema, adicionar blank=Trueao created_atcampo está funcionando, mas não é bom o suficiente. A melhor maneira é criar um ModelForm com apenas campos relacionados .

from django import forms

class EventForm(forms.ModelForm):
    class Meta:
        model = Event
        fields = ('name',)

class EventCreateView(CreateView):
    model_form = EventForm

A conclusão que tirei disso é que usar o Form para lidar com os dados do formulário postados pelo usuário é sempre uma boa prática, mesmo que o Form pareça não ter feito nada.