Django 1.1 の場合。
私の models.py には次の内容があります:
class User(models.Model):
created = models.DateTimeField(auto_now_add=True)
modified = models.DateTimeField(auto_now=True)
行を更新すると次のようになります:
[Sun Nov 15 02:18:12 2009] [error] /home/ptarjan/projects/twitter-meme/django/db/backends/mysql/base.py:84: Warning: Column 'created' cannot be null
[Sun Nov 15 02:18:12 2009] [error] return self.cursor.execute(query, args)
私のデータベースの関連部分は次のとおりです。
`created` datetime NOT NULL,
`modified` datetime NOT NULL,
これは心配すべきことでしょうか?
補足質問ですが、私の管理ツールでは、これら 2 つのフィールドが表示されません。これは想定内のことでしょうか?
ベストアンサー1
任意のフィールドauto_now
属性セットも継承されるeditable=False
ため、管理パネルには表示されません。過去には、およびを作成するという話がありましたauto_now
。auto_now_add
議論は消え去り、議論は依然として存在するが、私は単にカスタムsave()
メソッド。
したがって、これを適切に機能させるには、またはを使用せauto_now
ずauto_now_add
、代わりに独自のメソッドを定義して、が設定されていない場合にのみ更新されるsave()
ようにし(アイテムが最初に作成されたときなど)、アイテムが保存されるたびに更新されるようにすることをお勧めします。created
id
modified
私は Django を使用して作成した他のプロジェクトでもまったく同じことを行いました。そのため、save()
次のようになります。
from django.utils import timezone
class User(models.Model):
created = models.DateTimeField(editable=False)
modified = models.DateTimeField()
def save(self, *args, **kwargs):
''' On save, update timestamps '''
if not self.id:
self.created = timezone.now()
self.modified = timezone.now()
return super(User, self).save(*args, **kwargs)
コメントに応じて編集:
これらのフィールド引数に頼るのではなく、オーバーロードに固執する理由はsave()
2 つあります。
- 前述の信頼性の長所と短所。これらの議論は、Django が対話する方法を知っている各タイプのデータベースが日付/タイムスタンプ フィールドを処理する方法に大きく依存しており、リリースごとに壊れたり変更されたりするようです。(これが、これらを完全に削除するという呼びかけの背後にある原動力であると私は信じています)。
- これらは DateField、DateTimeField、および TimeField でのみ機能し、この手法を使用すると、アイテムが保存されるたびに任意のフィールド タイプを自動的に入力できます。
- に応じてTZ 対応オブジェクトまたはナイーブ オブジェクトを返すため、
django.utils.timezone.now()
と を使用します。datetime.datetime.now()
datetime.datetime
settings.USE_TZ
OP がエラーを見た理由については、正確にはわかりませんが、created
があるにもかかわらず、 がまったく入力されていないように見えますauto_now_add=True
。私にとっては、これはバグとして目立っており、上記の短いリストの項目 1 を強調しています。つまりauto_now
、 とauto_now_add
はせいぜい不安定です。