Question

I am trying to implement an audit trail into my application, but because of some requirements I am unable to use any existing gems or plugins.

I would like to divert any normal attempt to update a model to a custom method that saves all the updates in another separate Table (called Updates).

The application then uses the update table to actually perform the update.

Right now I have overloaded create_or_update to get the first part of the functionality

def create_or_update
  raise ReadOnlyRecord if readonly?
  result = new_record? ? create : create_updates
  result != false
end


class Update < ActiveRecord::Base
  belongs_to :updatable, :polymorphic => true

  after_create :update_model

  private

  def update_model
    self.updatable.update_attribute self.attribute, self.new_value #infinite loop
  end
end  

The issue now is that this causes an infinite loop when the Update Model tries to actually perform the update.

I have been looking through the rails core source to find the best place to bypass the functionality of the first feature. I would like these updates to be performed inside of the transaction but I am not sure where exactly that begins or ends in the active record stack. I also do not want to start hacking away at active resource.

Any suggestions would be greatly appreciated.

Answer 1

Do you actually need to save the attributes in a separate table, and then perform the update after an administrator views and approves them? If this is the scenario, you may just want to overwrite the update method to do something like this:

def update(perform_updates = false)
  if perform_updates
    latest_approved_update = UpdateAuditor.first(:conditions => { :updatable_id => self.id, :updatable_type => self.class.name, :approved => true })
    self.attributes = latest_approved_update.attributes
    self.save
  else 
    UpdateAuditor.create(:updatable_id => self.id, :updatable_type => self.class.name, :attributes => self.attributes)
  end
end

UPDATE: The author has commented that they want to be able to apply this model to all updates. In order to accomplish this, you can add an attr_accessor to the model, let’s say something like “perform_updates”, which will of course be nil by default.

When you want to perform the update to the database, you will first have to set the attribute to true, then run update. Otherwise, the update will just create a new UpdateAuditor record which will need to be approved by an administrator.

class Person < ActiveRecord::Base
  has_many :audits, :class_name => "UpdateAudit", :as => :auditable

  attr_accessor :perform_updates

  private

  def create_or_update
    raise ReadOnlyRecord if readonly?

    if new_record?
      result = create
      result != false
    else
      if perform_updates
        latest_approved_update = audits.approved.last

        if latest_approved_update
          self.attributes = latest_approved_update.attributes
          update
        else
          return false
        end
      else
        audits.create(:updated_attributes => self.attributes)
      end 
    end
  end
end

For the record, I think that overwriting the default update methods is a dangerous game, and such programming is better off in a before_update callback where it belongs. Once an update is approved in some interface, then an observer can then perform the update, overwriting what is currently there, until another change which was made can be approved. If there are currently updates to an object in the queue to be approved, users can be alerted that changes are pending approval, etc.