I've uploaded a new version of django-history-tables  to the mercurial repository. It now should run on Django 1.0 + 1.1 and finally supports (although basically) the Admin interface.
For those that don't know django-history-tables (guessing that's 99.9% of everybody reading this), it is a pluggable Django application to create addition tables inside the database recording the history of changes and deletion of Django models.
This in itself is not unique there are many more project out there doing basically the same but most implement this by serializing data (such as pickling, json, xml, etc). Big drawback of this approach is that when schema changes your serialized history does not change with it. Somewhere down the line when you have forgotten all the schema changes it will be most difficult to use this history data.
django-history-tables works by using one additional 'normal' database table to store history information; major benefit of this approach is that there's no pickling, no serializing, and it should be able to support anything that your database supports as well.
Schema changes in this approach needs to be applied to both tables. When you change your model, you will need to change the schema of the history table as well. <shameless-plug>By using my sqldiff extensions in django-extensions this process can be made pretty easy.</shameless-plug>
In the future I hope to support the major schema migration tools for Django so that we can make schema changes in the history models even less painful.
It has been a while since I've worked on django-history-tables and truth be told I kinda forgot about it :-) It's been lingering in a corner for a while now and I've been busy doing other things like maintaining django-extensions and writing news sites in Django.
But then something really cool happened, something which is really telling for Open Source projects and the Open Source community as a hole. Somebody contacted me, out of the blue, an email from a stranger with the message that they had updated my old proof-of-concept code to run on new versions of Django with the patch attached.
We started talking and found that other people had written patches for it as well and put them up on the issue tracker at Google code. A project which was, for all intents and purposes dead to me, suddenly sparked back to live.
This inspired me to get to work again and to try to get the project back into some kind of shape.
Now it's not perfect yet, it will have bugs and needs more work. I can also do with some help improving it, making it better and reviewing that the implementation works as expected.
So please try it, play with it, have fun with it. And if you like it leave a message :)
|||Django History Tables: http://code.google.com/p/django-history-tables/|
Posted on January 23, 2010
|Looks good. I think I might use it on a project I'm working on.|
|Nice! I'm just now browsing for an app/tool to add versioning to our homebrewed CMS and this seems to involve less dark magic than django-reversion (or so it seems at first sight). I'll try it out in the next few days and get back to you.|
|Does this work with two foreign keys to the same model (say User)? I know the Audit Trail and HistoricalRecords both fail on this. The Audit Trail lists this issue in the caveats section of the wiki. thanks|
|Finally someone thinks in the same way as me - django-reversion pickling into database seems to me like a very bad idea (no queries possible to history of model + mentioned impossibility to make schema changes + non-django based application can't access the data). I'll check django-history-tables and maybe contact you too, as I have some ideas.|