Full History Tracking

TOC(inline)

Current status

(2011-02-04) this project seems dead. You can find an overview of versioning apps at ​http://stdbrouw.github.com/django-revisions/design.html and also find a new take on this feature at ​https://github.com/stdbrouw/django-revisions/.

(2009-07-13) django-modelhistory doesn't appear to be maintained anymore. Perhaps try ​fullhistory or ​django-reversion

(2008-11-02) Note: The ​django-modelhistory project in Google Code seems to be more up-to-date while implementing the same functionality as an external app –akaihola 2008-11-02

---

Features: almost there (15.03.2007)

Last trunk merge from 4724.

At the moment the contrib.history is quite useful. Examples below should work.

NOTE: Comparing and merging should be done by user and is not automated (yet).

WARNING!!! Names of functions may change. Please check this page for any changes.

Get the code

You can grab the current code from the "full-history" branch:

svn co http://code.djangoproject.com/svn/django/branches/full-history/

TODO

This is a general list of tasks, details are managed in a Basecamp project. If you want access drop me an email at urosDOTtrebecATgmailDOTcom.

Task	Status
Getting the code to work generically (on every given model)	DONE
Getting the code to a working state	DONE
Getting the API to work as described below	DONE
Unit tests	(under way)
Author handling (default Anonymous)
Admin UI integration	(later)
Decoupled App (can be used outside the branch)	DONE

Discussion

The ability to keep previous states of a table accessible is well described in Richard T. Snodgrass's (​http://www.cs.arizona.edu/~rts/) "Developing Time-Oriented Database Applications in SQL" (​http://www.cs.arizona.edu/people/rts/tdbbook.pdf). Adding the ability to designate a particular model as a transaction-time state table, with suitable methods added to the model's API, and with all queries defaulting to using either the current time or the latest time.

Introduction

The problem

The changelog-type of history in its current implementation, would write log only when using Admin and log would include only information about the change but not the content that was changed. This is not very useful when you would like to revert a change or even see what was changed.

The main idea

I am trying to write a different implementation that will be independent of Admin and will store the content as well. This way developers will be able to save, compare and revert any changes made in any particular model.

Usage

How to enable history tracking?

Settings

You need to add the following to settings.py:

INSTALLED_APPS = (
    'django.contrib.history',
)

Models

Enabling history tracking for a particular model is just like adding Admin functionality - add an inner class as shown below:

class Post(models.Model):
    author = models.CharField(maxlength=100) 
    title = models.CharField(maxlength=100)
    content = models.TextField()
    date = models.DateField(auto_now=True)

    class History:
        pass

When this is done every "Post" object will be saved to a "django_history_log" table when created, changed or deleted.

API

For this functionality to be really useful I need to create some listing, reverting and other functions.

List of all revisions of an object:

from django.contrib.history.models import ChangeLog

post = Post(author="Mort", title="Discworld is down!", content="Well, it's rather complicated...")
post.save()

rev_list = ChangeLog.objects.list_history(post) # Returns a complete list of versions for this object

List of latest 3 revisions of an object:

rev_list = ChangeLog.objects.list_history(post, offset=3) # Returns a list of latest 3 versions for this object

Get a date-specific list of revisions:

rev_list = ChangeLog.objects.version_by_date(post, datetime(2006, 07, 08))

Get a revision that is 3 revisions back:

rev_list = ChangeLog.objects.get_version(post, offset=3)

Get a specific revision (for example, 222):

rev_list = ChangeLog.objects.get_version(poll, revision=222)

Revert to a specific revision:

# NOT IMPLEMENTED!!! User should do the merging, comparing and reverting manually.