I would (and do) implement audit trails right in the database itself using the trigger and procedure language that your database provides.
In this manner, any front-end application writing to the database will have the audit-trail by default, without need for front-end application support. In other words, I don't believe that the application-level is the place to put the audit trail. - david On Apr 20, 10:30 am, "Jason McVetta" <[EMAIL PROTECTED]> wrote: > 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/f36f...>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 -~----------~----~----~----~------~----~------~--~---
