Django auto_now y auto_now_add

Para Django 1.1.

Tengo esto en mis models.py:

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

Al actualizar una fila obtengo:

[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 relevante de mi base de datos es:

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

¿Es esto motivo de preocupación?

Pregunta secundaria: en mi herramienta de administración, esos dos campos no se muestran. ¿Es eso esperado?

Cualquier campo con el auto_nowconjunto de atributos también heredará editable=Falsey, por lo tanto, no aparecerá en el panel de administración. Se ha hablado en el pasado sobre hacer que los argumentos auto_nowy auto_now_adddesaparezcan, y aunque todavía existen, creo que es mejor que solo use un método personalizadosave() .

Por lo tanto, para que esto funcione correctamente, recomendaría no usar auto_nowo auto_now_addy, en su lugar, definir su propio save()método para asegurarse de que createdsolo se actualice si idno está configurado (como cuando se creó el elemento por primera vez), y que se actualice modifiedcada vez que el elemento está guardado

He hecho exactamente lo mismo con otros proyectos que he escrito usando Django, y así save()se vería así:

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)

¡Espero que esto ayude!

Editar en respuesta a los comentarios:

La razón por la que me quedo con la sobrecarga en lugar de save()depender de estos argumentos de campo es doble:

1. Los altibajos mencionados anteriormente con su fiabilidad. Estos argumentos dependen en gran medida de la forma en que cada tipo de base de datos con la que Django sabe interactuar trata un campo de marca de fecha / hora, y parece romperse y / o cambiar entre cada lanzamiento. (Lo que creo es el ímpetu detrás de la llamada para que se eliminen por completo).
2. El hecho de que solo funcionan en DateField, DateTimeField y TimeField, y al usar esta técnica, puede completar automáticamente cualquier tipo de campo cada vez que se guarda un elemento.
3. Use django.utils.timezone.now()vs. datetime.datetime.now(), porque devolverá un datetime.datetimeobjeto ingenuo o consciente de TZ dependiendo de settings.USE_TZ.

Para abordar por qué el OP vio el error, no sé exactamente, pero parece que createdni siquiera se está poblando, a pesar de haberlo hecho auto_now_add=True. Para mí, se destaca como un error y subraya el elemento n. ° 1 en mi pequeña lista anterior: auto_nowy auto_now_adden el mejor de los casos es escamoso.

Pero quería señalar que la opinión expresada en la respuesta aceptada está algo desactualizada. De acuerdo con las discusiones más recientes (errores de django # 7634 y # 12785 ), auto_now y auto_now_add no irán a ninguna parte, e incluso si va a la discusión original , encontrará argumentos sólidos contra el RY (como en DRY) en el guardado personalizado métodos.

Se ha ofrecido una mejor solución (tipos de campo personalizados), pero no obtuvo el impulso suficiente para convertirse en django. Puedes escribir el tuyo en tres líneas (es la sugerencia 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)

Hablando de una pregunta secundaria: si desea ver estos campos en admin (sin embargo, no podrá editarlo), puede agregar readonly_fieldsa su clase de administrador.

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

Bueno, esto se aplica solo a las últimas versiones de Django (creo, 1.3 y superior)

Creo que la solución más fácil (y tal vez la más elegante) aquí es aprovechar el hecho de que puede establecer defaultuna opción invocable. Entonces, para evitar el manejo especial del administrador de auto_now, puede declarar el campo de esta manera:

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

Es importante que no lo use timezone.now()ya que el valor predeterminado no se actualizaría (es decir, el valor predeterminado se establece solo cuando se carga el código). Si te encuentras haciendo esto mucho, puedes crear un campo personalizado. Sin embargo, esto es bastante SECO ya creo.

Si modifica su clase de modelo así:

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

Entonces este campo aparecerá en mi página de cambio de administrador

Según lo que he leído y mi experiencia con Django hasta ahora, auto_now_add tiene errores. Estoy de acuerdo con jthanism --- anule el método normal de guardar, está limpio y sabe lo que está sucediendo. Ahora, para hacerlo seco, cree un modelo abstracto llamado 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

Y luego, cuando desee un modelo que tenga este comportamiento de marca de tiempo, simplemente subclase:

MyNewTimeStampyModel(TimeStamped):
    field1 = ...

Si desea que los campos se muestren en admin, simplemente elimine la editable=Falseopción

¿Es esto motivo de preocupación?

No, Django lo agrega automáticamente mientras guarda los modelos, por lo que se espera.

Pregunta secundaria: en mi herramienta de administración, esos 2 campos no se muestran. ¿Es eso esperado?

Como estos campos se agregan automáticamente, no se muestran.

Para agregar a lo anterior, como dijo synack, ha habido un debate sobre la lista de correo de django para eliminar esto, porque "no está bien diseñado" y es "un truco"

Escribir un save () personalizado en cada uno de mis modelos es mucho más doloroso que usar el auto_now

Obviamente no tienes que escribirlo en cada modelo. Puede escribirlo en un modelo y heredar otros de él.

Pero, como auto_addy auto_now_addestán allí, los usaría en lugar de tratar de escribir un método yo mismo.

Necesitaba algo similar hoy en el trabajo. El valor predeterminado es timezone.now(), pero editable tanto en vistas de administrador como de clase heredadas FormMixin, por lo que para mi creado, models.pyel siguiente código cumplía esos requisitos:

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

Para DateTimeField, supongo que eliminar el .date()de la función y cambiar datetime.datea datetime.datetimeo mejor timezone.datetime. No lo he probado con DateTime, solo con Date.

Puede usar timezone.now()para creado y auto_nowpara modificado:

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

Si está utilizando una clave primaria personalizada en lugar de la predeterminada auto- increment int, auto_now_addprovocará un error.

Aquí está el código del DateTimeField.pre_save predeterminado de Django con auto_nowy 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)

No estoy seguro de cuál es el parámetro add. Espero que sea algo como:

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

El nuevo registro no tendrá atributo id, por getattr(model_instance, 'id')lo que devolverá False conducirá a no establecer ningún valor en el campo.

En cuanto a su pantalla de administrador, vea esta respuesta .

Nota: auto_nowy auto_now_addestán configurados editable=Falsede manera predeterminada, razón por la cual esto se aplica.

auto_now=Trueno funcionó para mí en Django 1.4.1, pero el siguiente código me salvó. Es para datetime consciente de la zona horaria.

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)

Aquí, hemos creado y actualizado columnas que tendrán una marca de tiempo cuando se creen y cuando alguien modifique los comentarios.

auto_now_add establecerá la hora cuando se crea una instancia, mientras que auto_now establecerá la hora en que alguien modificó sus comentarios.

Aquí está la respuesta si está usando South y desea establecer de manera predeterminada la fecha en que agrega el campo a la base de datos:

Elija la opción 2 y luego: datetime.datetime.now ()

Se ve como esto:

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