Take the 2-minute tour ×

I have an app with a bunch of models and templates to perform a certain task (it's called a "user access review", but that's not important - the app is called "uar"). When the users have completed their task, we want to archive the data from the main models into what we're calling "history" tables. Those tables are identical in structure to the original "uar" tables, but may live in another database or may be in the same database. They will, however, be read-only except by the process that archives them into these history tables, and possibly a task that expires items after a certain number of years.

Since I wanted the exact same model structure but different names, I thought I'd just make an app called "uar_history" and symlink the models.py file between the two apps. But when I attempt to syncdb the new models, I get a lot of complaints about the models not validating because of the related_name back link on the foreign keys.

Is there a better approach to this? Should I just make all my archive tables sub-classes of the model classes instead?

share|improve this question
I would use an abstract model to hold the fields and then define concrete classes for the "regular" model, and one for the "history" model. That gives you some flexibility to easily add a new field on both models, or a field specific to only one model. –  Brandon Oct 16 '13 at 2:41
add comment

1 Answer

up vote 1 down vote accepted

@Brandon gave the right answer, you should use a common abstract model for the shared definition. They can be in the same file or separate model files (I chose common, current, and history as the apps for this example):


class CommonPostModel(models.Model):
    title = models.CharField(max_length=255)
    body = models.TextField()

    class Meta:
        abstract = True


class CurrentPostModel(CommonPostModel):


class ArchivePostModel(CommonPostModel):
share|improve this answer
Unfortunately this doesn't work for the foreign key relationships. When I make fields in common that are foreign keys to other models in common, when I instantiate them in history, I get an error about "CommonPerson has either not been installed or is abstract". –  Paul Tomblin Oct 16 '13 at 13:31
It looks like the solution to the foreign key problem is either GenericForeignKey, which might involve changing my existing code too much, or moving all ForeignKey fields out of the abstract models.py and into the concrete ones, which kind of ruins the beauty and DRYness of the abstract models.py. Hmmmm. –  Paul Tomblin Oct 16 '13 at 14:52
It works with ForeignKeys, but you can't use related_name (you need to let it automatically determine the reverse name). –  Kevin Stone Oct 16 '13 at 16:40
I had to use related_name because I have multiple foreign keys in the same model - for instance, I need to track who is being reviewed, as well as who they report to, and who did the review, and those are all FKs to the same "Person" table. –  Paul Tomblin Oct 16 '13 at 16:48
Related_name takes string formatting so you see if it works for abstract model fields. See docs.djangoproject.com/en/dev/topics/db/models/… –  Kevin Stone Oct 16 '13 at 18:23
show 1 more comment

Your Answer


