On 17/10/2016 9:11 AM, James Schneider wrote:
On Oct 15, 2016 11:40 PM, "Bernd Wechner" <bernd.wech...@gmail.com
<mailto: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 reminded me of a section in Marty Allchin's Pro Django - Keeping
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):
> Â # 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
--
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+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@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/CA%2Be%2BciVTYxHOOyqN3Zn0VSFrK-spBBWsKQsJqLJ11qvTRJ%2BuSA%40mail.gmail.com
<https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVTYxHOOyqN3Zn0VSFrK-spBBWsKQsJqLJ11qvTRJ%2BuSA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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/b3deb032-45d7-186e-2fbf-7c5bd228fdb7%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
