Django model version control

Discussion:

Erik Allik

2008-10-03 14:29:34 UTC

What if, for each model under version control, you'd create an
identical table (except the ID field would be a foreign key, not a
primary one). Any time a migration is run on that model, the same
migration could be run on the "twin" table, too.

Erik

That is a problem, to be sure, and I'm not sure if a reasonable
solution
exists.
As it stands, Django is currently lacking an automated rollback/
recovery
for models. The fullhistory branch tried to address this lack, but
seems to have been abandoned for the time being.
django-reversions implements this rollback/recovery facility in a way
that aims to be easy to integrate with existing projects. It improves
- Using the serialization framework instead of pickle.
- Allowing groups of changes to be grouped into revisions.
- Integration with newforms-admin.
Changes to database schemas will indeed break the rollback facility.
Given the mind-boggling vastness of possible schema migrations, I
honestly would not know how to begin to implement such a feature!
Nevertheless, I hope that django-reversions remains a useful tool.
David.

But your schema's will most likely change over time. And sometimes in
significant ways which do not have a likely default; e.g. splitting a
full_name field into a first_name and last_name field or visa-versa.
Now after applying this change to the database, how will
django-reversions work when you want to undo and go back to an
earlier
version of a record in this table ? (which didn't have this change)
The fields in the database/model now do not match against the
serialized
copy right ?
Bas

This discussion has been moved from django-developers.
To answer a pending question: This application is for tracking
versions
- django-evolution concerns itself with maintaining versions of
database schemas.
- django-reversion deals with maintaining versions of the model
data.
It does not integrate with subversion. Instead, it uses the django
serialization framework to store serialized models in a special
database
table.
David.

I've just released an open-source version control application for
Django. It is available for download from Google code.
http://code.google.com/p/django-reversion/
- Roll back to any point in a model's history - an unlimited undo
facility!
- Recover deleted models - never lose data again!
- Admin integration for maximum usability.
- Group related changes into revisions that can be rolled back
in a
single transaction.
- Automatically save a new version whenever your model changes
using
Django's flexible signalling framework.
- Automate your revision management with easy-to-use middleware.
It can be easily added to your existing Django project with an
absolute minimum of code changes.
It's so far been previewed by a half dozen developers, with good
feedback. I'd appreciate any comments / suggestions you may have
to
offer.

--
David Hall
Technical Lead
Etianen.com
Tel: 07896 106290
Web www.etianen.com
-------------------------------------------------------------------
Etianen.com is a small, professional web development agency that
specialises in fast-paced, creative development.
----------------- enlightened website development -----------------

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

jonknee

2008-10-03 19:53:42 UTC

Permalink

I've just released an open-source version control application for
Django. It is available for download from Google code.

Neat idea! I installed it and while it works for rolling back, it does
not work bring back deleted items. I did a little checking and it's
running into an exception in VersionAdmin.revision_view(). The problem
seems to be the object_id is None because that's how it's recorded in
the admin_log (since it's deleted). If this doesn't make sense let me
know and I'll give you more of a concrete example.

I've had to build rollback stuff before, so having this as a pluggable
app is a great time saver.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

David Hall

2008-10-04 14:17:40 UTC

Permalink

Hi Jonknee,

Thanks for the bug report, I've uploaded a patch which should take care
of that problem.

I've taken the liberty of inviting you to a django-reversion Google
discussion group. If you are interested in improving the system, I'd
love to hear your feedback and comments!

David.

Post by jonknee

I've just released an open-source version control application for
Django. It is available for download from Google code.

--
David Hall
Technical Lead
Etianen.com
Tel: 07896 106290

Email ***@etianen.com
Web www.etianen.com
-------------------------------------------------------------------
Ask for help at ***@etianen.com
Etianen.com is a small, professional web development agency that
specialises in fast-paced, creative development.
----------------- enlightened website development -----------------

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-***@googlegroups.com
To unsubscribe from this group, send email to django-users+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Bas van Oostveen

2008-10-04 07:23:21 UTC

Permalink

That is exactly what i did for a project :)

When you register a model for versioning, automagicly a new model is
created which the original model + an 'version-control' abstract base model
to add things like version numbers, datetimestamps, methods to diff between
versions etc. Also all unique restricted are removed from the 'history'
model to not create constraints problems.

So you can stuff like:
FooHistory.objects.get(rev=42)
FooHistory.objects.latest().diff(fooInstance)
FooHistory.objects.latest().revert()

Ofcourse now you need to migrate two tables instead of one, on a schema
change, but in most cases that's just repeating the migration.

This approach has worked very well for me. Though i havn't used it any
'big' projects.

Bas

Post by Erik Allik
What if, for each model under version control, you'd create an
identical table (except the ID field would be a foreign key, not a
primary one). Any time a migration is run on that model, the same
migration could be run on the "twin" table, too.
Erik

David Hall

2008-10-04 13:29:36 UTC

Permalink

I did consider such an approach, but this runs into a fair amount
confusion for things like model inheritance. Also, it would result in
vast quantities of database tables being created.

Likewise, custom fields would have to be treated carefully, as would
unique fields. Also if you have any ManyToMany relationships, these
linking tables would also have to be created.

None of these are insurmountable problems, but they would result in a
much more heavyweight application. Currently, django-reversion is a
very small app indeed, and will only contribute one extra database table
to your schema. This makes it very easy to integrate with existing
projects.

David.

Post by Bas van Oostveen
That is exactly what i did for a project :)
When you register a model for versioning, automagicly a new model is
created which the original model + an 'version-control' abstract base model
to add things like version numbers, datetimestamps, methods to diff between
versions etc. Also all unique restricted are removed from the 'history'
model to not create constraints problems.
FooHistory.objects.get(rev=42)
FooHistory.objects.latest().diff(fooInstance)
FooHistory.objects.latest().revert()
Ofcourse now you need to migrate two tables instead of one, on a schema
change, but in most cases that's just repeating the migration.
This approach has worked very well for me. Though i havn't used it any
'big' projects.
Bas

David Hall

2008-10-04 14:21:02 UTC

Permalink

I've created a Google group for discussing possible improvements to the
django-reversion project. The group is called 'django-reversion', and
is a good place to let your views be heard about enhancements to the system.

At some point I would like to put the project forward as a candidate for
the currently-inactive fullhistory branch. As such, your feedback and
suggestions are vital to making this application as bombproof as possible.

David.

I've just released an open-source version control application for
Django. It is available for download from Google code.
http://code.google.com/p/django-reversion/
- Roll back to any point in a model's history - an unlimited undo
facility!
- Recover deleted models - never lose data again!
- Admin integration for maximum usability.
- Group related changes into revisions that can be rolled back in a
single transaction.
- Automatically save a new version whenever your model changes using
Django's flexible signalling framework.
- Automate your revision management with easy-to-use middleware.
It can be easily added to your existing Django project with an
absolute minimum of code changes.
It's so far been previewed by a half dozen developers, with good
feedback. I'd appreciate any comments / suggestions you may have to
offer.

christian

2008-10-30 15:29:46 UTC

Permalink

I tried it out David, and it is simple and it works, I was just about
to make the same exact thing. Thank you!

Post by David Hall
I've created a Google group for discussing possible improvements to the
django-reversion project. The group is called 'django-reversion', and
is a good place to let your views be heard about enhancements to the system.
At some point I would like to put the project forward as a candidate for
the currently-inactive fullhistory branch. As such, your feedback and
suggestions are vital to making this application as bombproof as possible.
David.

I've just released an open-sourceversioncontrolapplication for
Django. It is available for download from Google code.
http://code.google.com/p/django-reversion/
- Roll back to any point in a model's history - an unlimited undo
facility!
- Recover deleted models - never lose data again!
- Admin integration for maximum usability.
- Group related changes into revisions that can be rolled back in a
single transaction.
- Automatically save a newversionwhenever your model changes using
Django's flexible signalling framework.
- Automate your revision management with easy-to-use middleware.
It can be easily added to your existing Django project with an
absolute minimum of code changes.
It's so far been previewed by a half dozen developers, with good
feedback. I'd appreciate any comments / suggestions you may have to
offer.