created_at / modified_at on all database tables

[Aron Podrigal]

Hi,

I'd like to propose a created_at / modified_at auto field to models so that one can just turn this functionality on by a setting in settings.py or within the models Meta settings.

I want these fields on both of the OneToOne related models when using concrete inheritance, thus using a TimeStampedBaseModel abstract model would cause these fields to clash. The reason I need created_at / updated_at on every table because Django is not the only app using the database I have other services sharing the same database. I assume having created_at updated_at fields on tables to be very common. I can imagine django creating those fields to all tables implicitly while handling those field collisions properly (eg.  When accessing model.created_at on a derived class it will return the value of that model. model.base_model.created_at would give access to its base model).

What are your thoughts?

[Florian Apolloner]

Settings.py is definitely not the way to go. As for Meta options: Feel free, just do it via your own Model subclass, there is no need for this to be in core imo.

[Schmitt, Christian]

I also think that this won't need to be in core since a Model Subclass works. We use this in our Application since we can't hard delete stuff so we overwritten the Model Field and the manager that all tables contain a date_deleted field which will be set when calling delete() objects.delete().

And the Code was really simple, just create a class that extends models.Model and specifiy it abstract = True and then you can inherit from it in every of your models.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5693dbd6-e789-4025-8a92-5b491269bf9e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Aron Podrigal]

The problem is with the field clashes. Consider the following

from django.db import models

class TimeStampedModel(models.Model):

    created_at = models.DateTimeField(auto_now_add=True)

    updated_at = models.DateTimeField(auto_now=True)

    class Meta:

        abstract = True

class Member(TimeStampedModel):

    member_id = models.CharField(max_length=255)

class EliteMember(Member, TimeStampedModel):

    additional_elite_data = models.TextField()

This results in the following system check error.

django.core.management.base.SystemCheckError: SystemCheckError: System check identified some issues:

ERRORS:

myapp.EliteMember.created_at: (models.E006) The field 'created_at' clashes with the field 'created_at' from model 'myapp.member'.

myapp.EliteMember.updated_at: (models.E006) The field 'updated_at' clashes with the field 'updated_at' from model 'myapp.member'.

System check identified 2 issues (0 silenced).

As I mentioned earlier, if EliteMember would not inherit from TimeStampedModel, EliteMember   would not have the 'created_at' and  'updated_at' columns. And I do need that even on the inherited tables. So this would require special handling in ModelBase and perhaps while executing the queries against the tables.

[Shai Berger]

Hi Aron,

I think this feature does not belong in Django; hiding concrete parent fields
sounds like a bad idea which is likely to open a whole can of worms and
violated assumptions.

Since the motivation for the unusual parent-and-child-fields comes from non-
Django uses of the database, I suspect the solution should be there as well --
that is, in database artifacts which are not reflected as Django fields. These
could be database columns and triggers, or. If other users only read, it could
be done by presenting them with views rather than the underlying tables (in
fact, this could also be done if they write -- if I recall correctly, PG views
support "instead of insert/update" triggers).

Such columns, triggers and/or views can be created either outside of Django or
via RunSQL migration operations.

HTH,
Shai.