Hi Jeff, How did you pass the userid to the trigger for auditing? Are you able to post what you did? (e.g. I intend to ''hack'' on postgresql_adapter.rb). I''m wondering whether for me (so having to get too deep into mysqltriggers/stored procedures - if it has them, haven''t checked yet) whether an approach similar to "keeping track of who did what - Rails Receipes" would be easier. That is using a Cache:Sweeper to trigger a log statement which will have access to the session information. This could then pass the userid to a stored procedure to do the audit. I guess then this is non-DB specific and I may as well let the rails layer then write the audit information. PS. I''m also keen on your concept of 1 audit table only, with columns to store which table/column was changed. I''m thinking of complementing this table with an action based table which captures audit from the UI point of view, e.g. "UserA performed a Contact Edit & modified X,Y,Z". If I include the concept of a transaction number for this I could also put this into the detailed database audit table and tie to the two tables together. E.g. For a given audit action I could then look up all the database attributes that were changed in relation to this transactions. Comments anyone? On 8/19/06, J Amiel <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > My solution is currently postgresql specific (and derived from a > solution currently used at me ''real'' job) > > Essentially, will have an ''audit'' table that contains user, table, > column, etc information that will be populated via triggers on each > table. Any time an insert, update or delete is performed, the triggers > kick off a series of entries to the audit table. I intend to ''hack'' on > postgresql_adapter.rb (wish me luck!) to ''do some trickery'' whenever a > database connection is requested via activerecord . That trickery > essentially sets up some transient data using temp tables that > postgresql can use via the triggers to know what ''user'' is actually > performing the database change and can audit appropriately. (outside of > rails, the system will log the database user that was used to connect as > well as the IP address) > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Michael Modica
2006-Aug-30 22:01 UTC
Re: DB record versioning/audit - Recommended Approach???
As previously mentioned, acts_as_versioned OR, something that may be more specific to you, acts_as_audited Both of which can be found at http://www.agilewebdevelopment.com/plugins/list/all Regards, Michael -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---