Django auto_now e auto_now_add

Per Django 1.1.

Ho questo nei miei modelli.py:

class User(models.Model):
    created = models.DateTimeField(auto_now_add=True)
    modified = models.DateTimeField(auto_now=True)

Quando aggiorno una riga ottengo:

[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)

La parte rilevante del mio database è:

  `created` datetime NOT NULL,
  `modified` datetime NOT NULL,

Questa è motivo di preoccupazione?

Domanda a margine: nel mio strumento di amministrazione, questi due campi non vengono visualizzati. È previsto?

Anche qualsiasi campo con l' auto_nowattributo impostato erediterà editable=Falsee pertanto non verrà visualizzato nel pannello di amministrazione. In passato si è parlato di far sparire gli argomenti auto_nowe auto_now_add, e sebbene esistano ancora, sento che stai meglio usando solo un metodo personalizzatosave() .

Quindi, per far funzionare correttamente questo, consiglierei di non usare auto_nowo auto_now_adde invece definire il proprio save()metodo per assicurarsi che createdsia aggiornato solo se idnon è impostato (come quando l'elemento viene creato per la prima volta), e farlo aggiornare modifiedogni volta che l'articolo è salvato.

Ho fatto esattamente la stessa cosa con altri progetti che ho scritto usando Django, e quindi il tuo save()sarebbe simile a questo:

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)

Spero che questo ti aiuti!

Modifica in risposta ai commenti:

Il motivo per cui mi limito a sovraccaricare save()piuttosto che fare affidamento su questi argomenti di campo è duplice:

1. Gli alti e bassi di cui sopra con la loro affidabilità. Questi argomenti dipendono fortemente dal modo in cui ogni tipo di database con cui Django sa come interagire tratta un campo data / ora e sembra rompersi e / o cambiare tra ogni versione. (Che credo sia l'impulso dietro la chiamata a rimuoverli del tutto).
2. Il fatto che funzionano solo su DateField, DateTimeField e TimeField e utilizzando questa tecnica, è possibile popolare automaticamente qualsiasi tipo di campo ogni volta che viene salvato un elemento.
3. Usa django.utils.timezone.now()vs. datetime.datetime.now(), perché restituirà un oggetto TZ-aware o ingenuo a datetime.datetimeseconda settings.USE_TZ.

Per capire perché l'OP abbia visto l'errore, non lo so esattamente, ma sembra che creatednon sia nemmeno stato popolato, nonostante ciò auto_now_add=True. Per me si distingue come un bug e sottolinea l'articolo 1 nella mia piccola lista sopra: auto_nowe auto_now_addnella migliore delle ipotesi è traballante.

Ma volevo sottolineare che l'opinione espressa nella risposta accettata è in qualche modo obsoleta. Secondo discussioni più recenti (django bugs # 7634 e # 12785 ), auto_now e auto_now_add non stanno andando da nessuna parte, e anche se vai alla discussione originale , troverai argomenti forti contro il RY (come in DRY) nel salvataggio personalizzato metodi.

È stata offerta una soluzione migliore (tipi di campo personalizzati), ma non ha guadagnato abbastanza slancio per trasformarlo in django. Puoi scrivere il tuo in tre righe (è il suggerimento di Jacob Kaplan-Moss ).

from django.db import models
from django.utils import timezone


class AutoDateTimeField(models.DateTimeField):
    def pre_save(self, model_instance, add):
        return timezone.now()

#usage
created_at = models.DateField(default=timezone.now)
updated_at = models.AutoDateTimeField(default=timezone.now)

Parlando di una domanda secondaria: se vuoi vedere questi campi in admin (però, non sarai in grado di modificarlo), puoi aggiungere readonly_fieldsalla tua classe admin.

class SomeAdmin(ModelAdmin):
    readonly_fields = ("created","modified",)

Bene, questo vale solo per le ultime versioni di Django (credo, 1.3 e successive)

Penso che la soluzione più semplice (e forse più elegante) qui sia quella di sfruttare il fatto che è possibile impostare defaultun callable. Quindi, per aggirare la gestione speciale di auto_now da parte dell'amministratore, puoi semplicemente dichiarare il campo in questo modo:

from django.utils import timezone
date_filed = models.DateField(default=timezone.now)

È importante non utilizzarlo timezone.now()poiché il valore predefinito non viene aggiornato (ovvero, il valore predefinito viene impostato solo quando viene caricato il codice). Se ti ritrovi a fare molto, potresti creare un campo personalizzato. Tuttavia, questo è abbastanza ASCIUTTO già penso.

Se si modifica la classe del modello in questo modo:

class MyModel(models.Model):
    time = models.DateTimeField(auto_now_add=True)
    time.editable = True

Quindi questo campo verrà visualizzato nella mia pagina di modifica dell'amministratore

Sulla base di ciò che ho letto e della mia esperienza con Django finora, auto_now_add è difettoso. Sono d'accordo con il jthanismo --- scavalcare il normale metodo di salvataggio è pulito e sai cosa sta succedendo. Ora, per renderlo asciutto, crea un modello astratto chiamato TimeStamped:

from django.utils import timezone

class TimeStamped(models.Model):
    creation_date = models.DateTimeField(editable=False)
    last_modified = models.DateTimeField(editable=False)

    def save(self, *args, **kwargs):
        if not self.creation_date:
            self.creation_date = timezone.now()

        self.last_modified = timezone.now()
        return super(TimeStamped, self).save(*args, **kwargs)

    class Meta:
        abstract = True

E poi, quando si desidera un modello con questo comportamento scadente, basta eseguire una sottoclasse:

MyNewTimeStampyModel(TimeStamped):
    field1 = ...

Se desideri che i campi vengano visualizzati in admin, rimuovi semplicemente l' editable=Falseopzione

Questa è motivo di preoccupazione?

No, Django lo aggiunge automaticamente per te durante il salvataggio dei modelli, quindi è previsto.

Domanda a margine: nel mio strumento di amministrazione, quei 2 campi non vengono visualizzati. È previsto?

Poiché questi campi vengono aggiunti automaticamente, non vengono visualizzati.

Per aggiungere a quanto sopra, come ha detto Synack, c'è stato un dibattito sulla mailing list di django per rimuovere questo, perché "non è ben progettato" ed è "un hack"

Scrivere un save () personalizzato su ciascuno dei miei modelli è molto più doloroso che usare auto_now

Ovviamente non devi scriverlo su ogni modello. Puoi scriverlo su un modello ed ereditarne altri.

Ma, come auto_adde auto_now_addsono lì, li userei piuttosto che provare a scrivere un metodo da solo.

Avevo bisogno di qualcosa di simile oggi al lavoro. Valore predefinito da essere timezone.now(), ma modificabile sia nelle viste di amministrazione che di classe ereditate da FormMixin, quindi per creato nel mio models.pyil seguente codice ha soddisfatto tali requisiti:

from __future__ import unicode_literals
import datetime

from django.db import models
from django.utils.functional import lazy
from django.utils.timezone import localtime, now

def get_timezone_aware_now_date():
    return localtime(now()).date()

class TestDate(models.Model):
    created = models.DateField(default=lazy(
        get_timezone_aware_now_date, datetime.date)()
    )

Perché DateTimeField, suppongo di rimuovere il .date()dalla funzione e passare datetime.datea datetime.datetimeo meglio timezone.datetime. Non l'ho provato con DateTime, solo con Date.

È possibile utilizzare timezone.now()per creato e auto_nowmodificato:

from django.utils import timezone
class User(models.Model):
    created = models.DateTimeField(default=timezone.now())
    modified = models.DateTimeField(auto_now=True)

Se si utilizza una chiave primaria personalizzata anziché quella predefinita auto- increment int, si auto_now_addverificherà un bug.

Ecco il codice del DateTimeField.pre_save predefinito di Django con auto_nowe auto_now_add:

def pre_save(self, model_instance, add):
    if self.auto_now or (self.auto_now_add and add):
        value = timezone.now()
        setattr(model_instance, self.attname, value)
        return value
    else:
        return super(DateTimeField, self).pre_save(model_instance, add)

Non sono sicuro di quale sia il parametro add. Spero che qualcosa del genere:

add = True if getattr(model_instance, 'id') else False

Il nuovo record non avrà attr id, quindi getattr(model_instance, 'id')restituirà False porterà a non impostare alcun valore nel campo.

Per quanto riguarda il display dell'amministratore, vedi questa risposta .

Nota: auto_nowe auto_now_addsono impostati di editable=Falsedefault, motivo per cui questo vale.

auto_now=Truenon ha funzionato per me in Django 1.4.1, ma il codice seguente mi ha salvato. È per datetime consapevole del fuso orario.

from django.utils.timezone import get_current_timezone
from datetime import datetime

class EntryVote(models.Model):
    voted_on = models.DateTimeField(auto_now=True)

    def save(self, *args, **kwargs):
        self.voted_on = datetime.now().replace(tzinfo=get_current_timezone())
        super(EntryVote, self).save(*args, **kwargs)

class Feedback(models.Model):
   feedback = models.CharField(max_length=100)
   created = models.DateTimeField(auto_now_add=True)
   updated = models.DateTimeField(auto_now=True)

Qui, abbiamo creato e aggiornato colonne che avranno un timestamp quando vengono create e quando qualcuno ha modificato il feedback.

auto_now_add imposterà l'ora in cui viene creata un'istanza mentre auto_now imposterà l'ora in cui qualcuno ha modificato il proprio feedback.

Ecco la risposta se stai usando south e vuoi impostare come predefinito la data in cui aggiungi il campo al database:

Scegli quindi l'opzione 2 : datetime.datetime.now ()

Somiglia a questo:

$ ./manage.py schemamigration myapp --auto
 ? The field 'User.created_date' does not have a default specified, yet is NOT NULL.
 ? Since you are adding this field, you MUST specify a default
 ? value to use for existing rows. Would you like to:
 ?  1. Quit now, and add a default to the field in models.py
 ?  2. Specify a one-off value to use for existing columns now
 ? Please select a choice: 2
 ? Please enter Python code for your one-off default value.
 ? The datetime module is available, so you can do e.g. datetime.date.today()
 >>> datetime.datetime.now()
 + Added field created_date on myapp.User