- Blog Code
- Open source
- Quasi-philosophic ramblings
- Site news
Versioning objects in a Django application
For a project that I've been working on, one thing that I've wanted was the ability to version objects in a Django application, and then go back to old versions and revert or see who made changes. I did a bit of research on what's available to this so I didn't have to implement it myself. In the hopes of saving other people even that effort, I'm posting those (somewhat cleaned up) notes for others to use. The short form is that I picked django-reversion. I haven't yet regretted that, though I definitely haven't used it much yet.
The main things I was considering are:
- License: if I'm going to use something, I'd kinda prefer it not be "all rights reserved". Just about any OSS license would work, though.
- Activity and sustainability: I'd like a project that isn't going to break in a couple of years when Django makes a backwards-incompatible change. To this end, I prefer something with recent changes, but also one that's been around for a while (it's hard to tell the difference between "one month old project that will be around in two years" and "random weekend project", but it's a little less likely to disappear if somebody has been actively developing it for years).
- Documentation: while I'm willing to read the source (and often will when I find bugs or just want to figure out how to do something weird), when getting started I like to have documentation available.
- Design: this one's a bit wishy-washy. Does the design feel clean, performant, etc.? More than anything else, this is an attribute that I found without really expecting to use it to pick my system.
The information in here is largely from late May, though I did check "latest commit" dates (with the exception of django-reversion, they hadn't really changed --- AuditTrail did grow a partial copyright statement, though).
This app is sometimes known as django-versioning instead (e.g., in the docs), which probably isn't a great sign.
- License: Berkeley 2-clause (?)
- Activity and sustainability: First commit August 2010, last commit March 2011. My pull request from May to fix the names in the docs hasn't been acted on at all (as of posting this in July).
- Somewhat limited documentation
In terms of the technical aspects:
- Store every version in the table with the model
- Provide accessors for getting the most recent version
- Appears not to support linking to a "bundle" (an object, not a version) --- see https://github.com/stdbrouw/django-revisions/issues/5
- Performance may be an issue --- https://github.com/stdbrouw/django-revisions/issues/9
- It's not immediately clear to me how to make the admin also save the old version
- License: unknown
- Never had a real website or source code repo, AFAICT --- just a page on the Django wiki
- Activity and sustainability: first "commit" August 2007, last "commit" August 2010 (except a comment clarifying the license of a bit of the code)
- Very limited documentation --- just the aforementioned Django wiki page
- Design: store versions in a shadow table per-model
- Listed under "Models, database, history, trails" on Django resources page
- License: GPLv2
- Activity: first commit August 2008, last January 2010
On the technical front:
- Store all versions of all models in a single table, using JSON
- Metadata (time, editor, some other stuff) stored unpickled
- License: Berkeley 3-clause
- Activity: first commit September 2008, last July 2011 (was April 2011 in May)
- Decent-looking documentation
On the technical front:
- Store all versions of all models in a single table, pickled
- Metadata (time, editor, comment) stored unpickled
- I'm a bit concerned that the "here are the changes that have been made" view might be too slow; as long as we limit to editor and time this should be fine
As I mentioned, I picked django-reversion (after a brief trial of django-revisions, which I decided wasn't working out). I think the high-looking chances of actually being updated and decent docs convinced me. In terms of design, I think I prefer the shadow-table-per-model approach of AuditTrail, but...
So far, the django-reversion upstream looks active and responsive, which is nice (though I haven't had to file any bugs or pull requests yet, so I could be mistaken).
- Open source