Overload and Bypass Active Record Update
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.attri开发者_开发技巧bute, 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.
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.
精彩评论