Django auto_now et auto_now_add

Pour Django 1.1.

J'ai ceci dans mes models.py:

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

Lors de la mise à jour d'une ligne, j'obtiens:

[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 partie pertinente de ma base de données est:

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

Est-ce une source de préoccupation?

Question secondaire: dans mon outil d'administration, ces deux champs n'apparaissent pas. Est-ce attendu?

Tout champ avec l' auto_nowattribut défini héritera également editable=Falseet n'apparaîtra donc pas dans le panneau d'administration. Il a été question dans le passé de faire disparaître les arguments auto_nowet auto_now_add, et bien qu'ils existent toujours, je pense que vous feriez mieux d'utiliser une méthode personnaliséesave() .

Donc, pour que cela fonctionne correctement, je vous recommande de ne pas utiliser auto_nowou auto_now_addet de définir votre propre save()méthode pour vous assurer qu'elle createdn'est mise à jour que si elle idn'est pas définie (comme lorsque l'élément est créé pour la première fois), et la mettre à jour à modifiedchaque fois que l'élément est enregistré.

J'ai fait exactement la même chose avec d'autres projets que j'ai écrits en utilisant Django, et ainsi vous save()ressembleriez à ceci:

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)

J'espère que cela t'aides!

Modifier en réponse aux commentaires:

La raison pour laquelle je reste fidèle à la surcharge par save()rapport à l'utilisation de ces arguments de champ est double:

1. Les hauts et les bas susmentionnés avec leur fiabilité. Ces arguments dépendent fortement de la façon dont chaque type de base de données avec lequel Django sait interagir traite un champ d'horodatage et semble rompre et / ou changer entre chaque version. (Ce qui, à mon avis, est l'impulsion derrière l'appel à les faire supprimer complètement).
2. Le fait qu'ils ne fonctionnent que sur DateField, DateTimeField et TimeField et qu'en utilisant cette technique, vous pouvez remplir automatiquement n'importe quel type de champ chaque fois qu'un élément est enregistré.
3. Utilisez django.utils.timezone.now()vs. datetime.datetime.now(), car cela retournera un datetime.datetimeobjet sensible à TZ ou naïf selon settings.USE_TZ.

Pour savoir pourquoi le PO a vu l'erreur, je ne sais pas exactement, mais il semble que ce createdne soit même pas du tout peuplé, malgré le fait auto_now_add=True. Pour moi, il s'agit d'un bug et souligne l'élément n ° 1 dans ma petite liste ci-dessus: auto_nowet auto_now_addest au mieux feuilleté.

Mais je voulais souligner que l'opinion exprimée dans la réponse acceptée est quelque peu dépassée. Selon des discussions plus récentes (bogues django # 7634 et # 12785 ), auto_now et auto_now_add ne vont nulle part, et même si vous allez à la discussion d'origine , vous trouverez des arguments solides contre le RY (comme dans DRY) dans la sauvegarde personnalisée méthodes.

Une meilleure solution a été proposée (types de champs personnalisés), mais n'a pas pris suffisamment d'élan pour en faire django. Vous pouvez écrire le vôtre en trois lignes (c'est la suggestion de 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)

En parlant d'une question secondaire: si vous voulez voir ces champs dans admin (bien que vous ne puissiez pas le modifier), vous pouvez ajouter readonly_fieldsà votre classe admin.

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

Eh bien, cela ne s'applique qu'aux dernières versions de Django (je crois, 1.3 et plus)

Je pense que la solution la plus simple (et peut-être la plus élégante) ici est de tirer parti du fait que vous pouvez définir defaultun appelable. Donc, pour contourner la gestion spéciale par admin de auto_now, vous pouvez simplement déclarer le champ comme suit:

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

Il est important de ne pas l'utiliser timezone.now()car la valeur par défaut ne serait pas mise à jour (c'est-à-dire que la valeur par défaut n'est définie que lorsque le code est chargé). Si vous vous retrouvez souvent à faire cela, vous pouvez créer un champ personnalisé. Cependant, c'est déjà assez sec, je pense.

Si vous modifiez votre classe de modèle comme ceci:

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

Ensuite, ce champ apparaîtra dans ma page de changement d'administrateur

D'après ce que j'ai lu et mon expérience avec Django jusqu'à présent, auto_now_add est bogué. Je suis d'accord avec jthanism --- remplacer la méthode de sauvegarde normale, c'est propre et vous savez ce qui se passe. Maintenant, pour le rendre sec, créez un modèle abstrait appelé 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

Et puis, quand vous voulez un modèle qui a ce comportement horodaté, il suffit de sous-classe:

MyNewTimeStampyModel(TimeStamped):
    field1 = ...

Si vous souhaitez que les champs apparaissent dans l'administrateur, supprimez simplement l' editable=Falseoption

Est-ce une source de préoccupation?

Non, Django l'ajoute automatiquement pour vous lors de la sauvegarde des modèles, c'est donc normal.

Question secondaire: dans mon outil d'administration, ces 2 champs n'apparaissent pas. Est-ce attendu?

Étant donné que ces champs sont ajoutés automatiquement, ils ne sont pas affichés.

Pour ajouter à ce qui précède, comme l'a dit synack, il y a eu un débat sur la liste de diffusion django pour le supprimer, car il n'est "pas bien conçu" et est "un hack".

Écrire un save () personnalisé sur chacun de mes modèles est beaucoup plus difficile que d'utiliser l'auto_now

De toute évidence, vous n'avez pas à l'écrire sur tous les modèles. Vous pouvez l'écrire sur un modèle et en hériter d'autres.

Mais, comme auto_addet auto_now_addsont là, je les utiliserais plutôt que d'essayer d'écrire une méthode moi-même.

J'avais besoin de quelque chose de similaire aujourd'hui au travail. La valeur par défaut est timezone.now(), mais modifiable à la fois dans les vues d'administration et de classe héritées de FormMixin, donc pour créé dans mon, models.pyle code suivant remplit ces conditions:

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

Pour DateTimeField, je suppose que supprimer le .date()de la fonction et changer datetime.datepour datetime.datetimeou mieux timezone.datetime. Je ne l'ai pas essayé avec DateTime, seulement avec Date.

Vous pouvez utiliser timezone.now()pour créé et auto_nowpour modifié:

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

Si vous utilisez une clé primaire personnalisée au lieu de la valeur par défaut auto- increment int, auto_now_addcela entraînera un bogue.

Voici le code de DateTimeField.pre_save par défaut de Django avec auto_nowet 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)

Je ne sais pas quel est le paramètre add. J'espère que ce sera quelque chose comme:

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

Le nouvel enregistrement n'aura pas d'attr id, donc getattr(model_instance, 'id')retournera False conduira à ne définir aucune valeur dans le champ.

Quant à votre écran Admin, voyez cette réponse .

Remarque: auto_nowet auto_now_addsont définis editable=Falsepar défaut, c'est pourquoi cela s'applique.

auto_now=Truen'a pas fonctionné pour moi dans Django 1.4.1, mais le code ci-dessous m'a sauvé. C'est pour le datetime sensible au fuseau horaire.

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)

Ici, nous avons créé et mis à jour des colonnes qui auront un horodatage lors de la création et lorsque quelqu'un a modifié les commentaires.

auto_now_add fixera l'heure à laquelle une instance est créée tandis que auto_now fixera l'heure à laquelle quelqu'un modifiera ses commentaires.

Voici la réponse si vous utilisez le sud et que vous souhaitez définir par défaut la date à laquelle vous ajoutez le champ à la base de données:

Choisissez l'option 2 puis: datetime.datetime.now ()

Ressemble à ça:

$ ./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