Re: implement audit trail table

Corey Lawson
Tue, 26 Jul 2005 17:21:19 -0000

On 7/25/05, Rick Olson
<technoweenie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 7/25/05, Paul Chin
<paulchin-0SqPFV7GnR3FK4RKhr3rmg@public.gmane.org> wrote:
> > has anyone has any idea how to implement audit trail table for all
update /
> > deletion done on records?
> >
> > I''m thinking to have corresponding audit trail table to each
table, so
> > everthing before an update or deletion is done, a new record will be
insert
> > into the corresponding audit trail table.
> >
> > Is there a way to overwrite the save, destroy, method at the
application
> > level? so that I do not need to overwrite it in every model file?
>
> I am working on such a mod:  http://dev.rubyonrails.org/ticket/1758
>
> You can override save/destroy, at the ActiveRecord::Base class, but
> it''s probably better to use callbacks.  With the acts_as_versioned
> method, just do this:
>
> class Post < AR::Base
>   acts_as_versioned
> end
>
> I have a simple method for a migration to create the versioned table also.
>
> --
> rick
> http://techno-weenie.net
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

DHH mentions in the list how to implement the "Observer" pattern that
is in ActiveRecord.

Probably better to do it more or less invisibly in the database if you
can via triggers, if your data is auditable... It''s generally possible
in SQL Server, Postgres, (DB2, ) and Oracle to shmoosh relevant data
together like in a field:delta, field:delta, etc. string for what has
been changed, too, before the actual record is posted in the regular
table.

Another idea is to not really delete records from the app, but just
mark them for deletion.