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?
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
On Tuesday 26 July 2005 04:14, Rick Olson wrote:> I am working on such a mod: http://dev.rubyonrails.org/ticket/1758I''ve only looked at it cursorily. Do you intend to implement versioning for habtm associations, too? Michael -- Michael Schuerig I am the sum total of the parts mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org I control directly. http://www.schuerig.de/michael/ --Daniel C. Dennett, Elbow Room
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.
On Tuesday 26 July 2005 19:21, Corey Lawson wrote:> 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.I favor the trigger approach, too, but I''m not convinced that a single table can do the job of holding differences of all kinds. I haven''t tried this before, though. Have you done this successfully? Michael -- Michael Schuerig Failures to use one''s frontal lobes mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org can result in the loss of them. http://www.schuerig.de/michael/ --William H. Calvin
On 7/26/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> On Tuesday 26 July 2005 04:14, Rick Olson wrote: > > I am working on such a mod: http://dev.rubyonrails.org/ticket/1758 > > I''ve only looked at it cursorily. Do you intend to implement versioning > for habtm associations, too? > > MichaelI don''t think versioning that would be very interesting really. habtm tables usually don''t even have keys, so are rarely updated. Now, if you have a @developer and you want to version it''s projects, you could use a before_save that serialized the project info to a text column and version that. Taking that approach further, I could add an option like so: class Developer < AR::Base habtm :projects acts_as_versioned :serialize => [ :projects ] end It could create a virtual versioned_projects attribute in your model and save it to an actual versioned_projects field in the versions table in before_save. Thoughts? -- rick http://techno-weenie.net
The reason I''m trying to implement audit trigger in the application. batch process will be done at back end. I do not want batch update to be audited, this could generate high overhead. -----Original Message----- From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org]On Behalf Of Michael Schuerig Sent: Wednesday, July 27, 2005 1:25 AM To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: [Rails] Re: implement audit trail table On Tuesday 26 July 2005 19:21, Corey Lawson wrote:> 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.I favor the trigger approach, too, but I''m not convinced that a single table can do the job of holding differences of all kinds. I haven''t tried this before, though. Have you done this successfully? Michael -- Michael Schuerig Failures to use one''s frontal lobes mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org can result in the loss of them. http://www.schuerig.de/michael/ --William H. Calvin _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails