A Backup Model in Django?
Bernd Wechner
from django.db import models
class MyModel(models.Model):
# Declare fields ....
class MyModel_backup(MyModel):
def create(self):
self.objects = MyModel.objects.all()- 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.
- I have no really idea how to copy all the objects of MyModel to a new model.
I could of course export a serialized backup to a disk file, but am exploring options for keeping one backup in the database itself.
Bernd.
Andromeda Yelton
--
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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a19ba010-572b-4097-a988-f357cc5b6c31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Vijay Khemlani
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFE1XCYW9cLixRSG2bmBM3Knm0hhf_4q%2BcZvuvvXcDPZmf9nKw%40mail.gmail.com.
James Schneider
On Oct 15, 2016 11:40 PM, "Bernd Wechner" <bernd....@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: https://docs.djangoproject.com/en/1.10/topics/db/models/#abstract-base-classes
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 model.
> 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 like this.
> 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 multiple strategies.
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 object.
There are a few packages that you might be able to take advantage of or use as reference:
https://github.com/etianen/django-reversion
https://github.com/treyhunner/django-simple-history
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).
-James
Mike Dewhirst
>
> On Oct 15, 2016 11:40 PM, "Bernd Wechner" <bernd....@gmail.com
> >
> > 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.
>
History Records
https://books.google.com.au/books?id=cpAV4bb1nYYC&pg=PA263&lpg=PA263&dq=pro+django+keeping+historical+records&source=bl&ots=1NLYKkRZzR&sig=QogOv-Kg6EReaBkcHaAwJA-vWKY&hl=en&sa=X&ved=0ahUKEwil5vDrr-DPAhVJKWMKHTzYDAoQ6AEIKTAC#v=onepage&q=pro%20django%20keeping%20historical%20records&f=false
If the notions suit your use-case you need to remember it was written
for Django 1.0 and Python >= 2.3. It may contain traces of
long-deprecated features but the principles are timeless.
Good luck
Mike
> This being the pro-forma so to speqk:
> >
> > from django.db import models
> >
> > class MyModel(models.Model):
> >
> > class MyModel_backup(MyModel):
> > Â def create(self):
> > Â self.objects = MyModel.objects.all()
> > Â
> > 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
>
> This one is easy. Create a single abstract model and have both of your
> models inherit from
> there:https://docs.djangoproject.com/en/1.10/topics/db/models/#abstract-base-classes
>
> 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 model.
> > 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
>
> 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 like this.
>
> > I could of course export a serialized backup to a disk file, but am
>
> 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
>
> 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 multiple strategies.
>
> 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 object.
>
> There are a few packages that you might be able to take advantage of
> or use as reference:
>
> https://github.com/etianen/django-reversion
> https://github.com/treyhunner/django-simple-history
>
> 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).
>
> -James
>
> 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
> <mailto:django-users...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVTYxHOOyqN3Zn0VSFrK-spBBWsKQsJqLJ11qvTRJ%2BuSA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Bernd Wechner
To those you recommended full database backup and/or transaction, my apologies for my lacking clarity. I'm well aware of the need for both and both are on the agenda, but not mysteries (well documented) and no need for me to ask about. Abstract classes were the clue I missed in my read of docs.
To clarify for anyone interested perchance, not to justify, just to clarify, the use case is a little like this:
- Raw data stored
- An expensive set of statics is calculated on that raw data and the aim of the whole site is to see these statistics. They too are abundant. But very expensive to calculate from the raw data. Well truth be told it's taking about 5 minutes with a few hundreds of raw data records to process. Pricey.
- For this reason the statistics are calculated on the fly as raw data is added and stored, so that they can be retrieved quickly on demand.
- Said statistics depend on a handful of configuration parameters, that need to be tuned as data is collected. Changing them demands a rebuild of all the stats.
- When doing such a rebuild it's very desirable to know what changed. In short to rebuild a table of stats and compare it with the table as it was before the rebuild and summarise what was impacted by the rebuild, and conceivably to undo if the impact is deemed undesirable (not an improvement).
- This could all over time involve rather serious quantities of data too - and stats on stats are the consequence, that is a table of calculated stats from raw data and configs, a backup of those stats before a config change, and stats on the differences between these tables ...
And the best way I see of doing that is to have two identically defined tables, back one up, rebuild, compare.
To wit, the abstract model and two identical tables suits my needs and is what I'm now in process of implementing.
Of course data entry is transactioned and the database will be backed up regularly, but they are separate issues.
Regards,
Bernd.