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
-~----------~----~----~----~------~----~------~--~---

Reply via email to