Thank you for the advice, David -- you make a good point. How would you track which Django user made which change? Perhaps I could subclass models.Model so save() always fills an (uneditable) field 'updated_by' with the current user. Likewise, we could have an (editable) field "reason_for_change" that would be written like normal, then cleared in the working record by the triggered procedure.
On Apr 20, 3:00 pm, drourke <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
