[Fixed]-Django AuditTrail vs Reversion


As i stated in my question rcField seems to be to much for my needs, which is simple that i want store any changes to my table, and may be come back later to those changes to generate some reports.

So I tested AuditTrail and Reversion
Reversion seems to be a better full blown application with many features(which i do not need), Also as far as i know it saves data in a single table in XML or YAML format, which i think

  1. will generate too much data in a single table
  2. to read that data I may not be able to use already present db tools.

AuditTrail wins in that regard that for each table it generates a corresponding audit table and hence changes can be tracked easily, per table data is less and can be easily manipulated and user for report generation.

So i am going with AuditTrail.


Personally I prefer to create audit tables in the database and populate through triggers so that any change even ad hoc queries from the query window are stored. I would never consider an audit solution that is not based in the database itself. This is important because people who are making malicious changes to the database or committing fraud are not likely to do so through the web interface but on the backend directly. Far more of this stuff happens from disgruntled or larcenous employees than outside hackers. If you are using an ORM already, your data is at risk because the permissions are at the table level rather than the sp level where they belong. Therefore it is even more important that you capture any possible change to the dat not just what was from the GUI. WE have a dynamic proc to create audit tables that is run whenever new tables are added to the database. Since our audit tables populate only the changes and not the whole record, we do not need to change them every time a field is added.

Also when evaluating possible solutions, make sure you consider how hard it will be to revert the data to undo a specific change. Once you have audit tables, you will find that this is one of the most important things you need to do from them. Also consider how hard it will be to maintian the information as the database schema changes.

Choosing a solution because it appears to be the easiest to understand, is not generally a good idea. That should be lowest of your selction criteria after meeting the requirements, security, etc.



I can’t give you real experience with any of them but would like to make an observation.

I assume by AuditTrail you mean AuditTrail on the Django wiki. If so, I think you’ll want to instead look at HistoricalRecords developed by the same author (Marty Alchin aka @gulopine) in his book Pro Django. It should work better with Django 1.x.

This is the approach I’ll be using on an upcoming project, not because it necessarily beats the others from a technical standpoint, but because it matches the “real world” expectations of the audit trail for that application.

Leave a comment