I need to add real audit trail and change-notification support to an existing Django app and to one that is under development. The best way to do this, it seems to me, is to add audit support to the Django framework itself. My requirements are similar to those named by Paul Childs in his django-users post<http://groups.google.com/group/django-users/browse_thread/thread/f36f4e48f9579fff>last June:
- rows, once written, are immutable -- system should be able to operate without UPDATE and DELETE privileges on the audit db - editing a record creates a new row (with higher version and/or date) but does not touch old record - deleting a record creates a new row to be created with the "record_is_deleted" flag set to true - (optional) whenever a new row is written, user must supply a comment explaining the change - (optional) whenever a new row is written, an email is sent to an address specified in the model To clarify, when I say "row" I mean a literal row in the database; and when I say "record" I mean the representation of a Django model. A record will have many rows associated with it in the audit db, if it has been modified many times. Audit trail support would be enabled on a per-model basis, probably by including an AuditTrail inner class. That inner class would then be used to specify audit options. Beyond including this inner class, and an to-be-determined method for attaching comments to changes, audit trail support should be invisible to developers. Both the existing admin log and the FullHistory <http://code.djangoproject.com/wiki/FullHistory>branch are inadequate for my requirements. I will be working on this project as part of my Real Job(tm), so devoting time to it should not be a problem. However, before I begin coding, I want the community's input on a few issues. What is the right way, at DB level, to implement the audit trail? I had two ideas: 1. The table representing a model with AuditTrail enabled will include fields such as "record_id", "row_id", "record_version", "record_is_deleted", and "row_timestamp". Row_id will be the primary key for the table, but will not be meaningful for identifying a given record. Record_id and record_version will be unique together, and together sufficient for locating the current version of a given record. Reading the current record can be accomplished by a query like "SELECT *, max(record_version) FROM table_name WHERE record_is_deleted IS FALSE GROUP BY record_id", or a database view encapsulating the same query. Advantage: The audit table is guaranteed to be in sync with the production data, since they are one and the same Disadvantage: Significantly heavier database load. 2. The audit table, as described above, is written seperately from the working table used for reads. It would be most useful if the audit table could be written to a wholly separate database. The working table is unchanged from today's Django. Advantage: Fairly trivial increase in database load Disadvantage: In the event of an application error, it would be possible for the working table and audit table to get out of sync 3. I am open to better suggestions. Perhaps the core developers can tell me, will it be possible to do this as a contrib plugin? I would, of course, rather do it as a plugin than hack on the Django core. But either way, my ultimate goal is to create a high quality solution that can be included in the main trunk. Lastly, would it have been more appropriate to post this to django-developers? Jason --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
