On Oct 15, 2016 11:40 PM, "Bernd Wechner" <bernd.wech...@gmail.com> wrote:
> A curious question I've had trouble finding an answer for alas. I have a
model that I'd like to backup in the database in a backup model. This being
the pro-forma so to speqk:
> from django.db import models
> class MyModel(models.Model):
> # Declare fields ....
> class MyModel_backup(MyModel):
> def create(self):
> self.objects = MyModel.objects.all()
> But there are two immediate problems.
> Deriving from MyModel reveals itself in the migration to be generating a
model which has a single OneToOne reference to MyModel. That is ti does not
appear to create a duplicate model at all. Which leaves me wondering how to
create a duplicate model without repeating the code.
This one is easy. Create a single abstract model and have both of your
models inherit from there:
This allows you to keep the fields in sync and avoids the extra OneToOne
relationship. The inherited models are completely unrelated and separate
models in separate tables. Note that ForeignKeys will also point to the
same spot, which may or may not be a problem, as others have pointed out.
> I have no really idea how to copy all the objects of MyModel to a new
> I may be approaching it poorly and am open to better ideas. I'm used to
doing it in SQL, essentially having an identically defined backup table,
just copying data to that table before doing a (risky) table wide operation
on the first.
Ah, the crux of the issue. Is this something that you perform often? A full
DB backup is always recommended.
Have you considered using transactions? Those were invented for situations
> I could of course export a serialized backup to a disk file, but am
exploring options for keeping one backup in the database itself.
If you go this route, do it with raw SQL. Trying to twist the ORM into
doing this will likely cause headaches, as others have pointed out,
especially with related fields.
> I'd rather, I admit hear options for doing that than philosophic
appraisals of the benefits of an in-database copy vs, database exports.
If you're doing this purely as a fail-safe, you're better off using other
methods (ie DB backup and transactions).
If you're doing this for archiving/historical tracking, then you'll want to
manually handle the process of copying the models anyway. There are
For instance, using an abstract model as the master, in your backup model
you can override the __init__() method to take an instance of your primary
model as an argument and copy all of the fields, and handle the foreign
keys appropriately. It could be as simple as providing a list of fields to
copy and praying through the primary object to copy them to the backup
There are a few packages that you might be able to take advantage of or use
I'm sure others exist, this was a quick Google. I don't believe these copy
the models as you desired, though (because it is difficult/impossible to do
without intimate knowledge of the model you are copying for anything beyond
a strict copy).
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.