Question

I’m working on this requirement: I have an object-relational model quite big, where entities are very strongly linked. Let us use, as example, this relationship: a building has many apartments, an apartment has many divisions. Now, what I want: when something changes on any division, I want to “inform” the building, or better, mark the building has being “updated” or “modified”.

• Current solution: we have a self-written implementation in which we would mark division as “affecting” building, and building’s “modified” timestamp would be updated each time a division would be updated.

• Desired solution: an already existing “out-of-the-box” implementation (a gem, a plugin, God, perhaps) which would spare us the work of refactoring our implementation.

• Unwanted solution: please, don’t tell me to mark all these associations with :autosave => true. I would like a solution which is queueable.

Solutions which do not comprise the desired solution but are either suggestions to improve the performance of the current solution are of course welcome as well. In lack of a desired solution we will most definitely improve on the existing one.

A small edit:

This behaviour has to be generic. It’s not only for buildings cases, but any model with associations can have this behaviour. Which will always be the same: fetch affected associations and update them. Now, I don’t want to write different observers with the same routine.

On the performance issue: Updated affected association updates must also trigger its affected associations. Now, let’s imagine 1 building affects 100 divisions, and each division affects 100 chairs. Now, the observer solution works only on the business level. That is, I have to instantiate every AR instance so that the observers can act. Which I hold as bad performance. If A affects 100 Bs, I do it with one DB statement. But how can the observers for these 100 be triggered when I do it all with SQL?

So, back to the main update points: this behaviour is generic, and most importantly, the performance has to be top (associations may trigger nxn updates for has_many associations, for instance).

Answer 1

So, the way I solve it was a mixture of the various suggestions concerning observer design pattern implementations. So, to start, none of the base implementations of the pattern work for me. Why? I wanted to have the concept of a model A observing its relation B, B being observed by its relation A, and the routine of this observation being defined somewhere else, in a (lets call it that) notifier.

Why couldn’t I use Ruby ‘observer’ library? In theory I could have achieved that, but the observed objects call a method called “changed” to notify its observers, and “changed” is a method which is overwritten by ActiveRecord, namely by the “dirty” library.

Why couldn’t I use AR ‘observers’? Because here the observer is what I want the notifier to be. The routine is not implemented in the model, but i couldn’t say which other AR models have to be notified. This was an hinderance.

How did I solve it? I created a library myself, using the ActiveModel::Observing library, which allowed me to implement the functionality I wanted. I designed to I would have this DSL:

class A < ActiveRecord
has_one :b

 observes :b, :on => :create, :notifiers => :update_observer

end

So this means, when b gets created, there is a notifier update_observer which can reach b and a and do something with it. so, in this case:

class UpdateObserverNotifier < Notifier

  def action(observable, observer)
    observer.update_attributes(updated_at: observable.updated_at)
  end
end

the DSL call on the observer will inject ‘observer’ and ‘observable’ behaviour in the respective classes. The Notifier base class will have notification behaviour, and it will have access to both the observable and the observer object, in case something from the observable has to be mirrored in the observer. And if your action triggers callbacks on the observer, it will also notify potential observers of the observer itself.

Yup, so this was it. Thanks for the suggestions, otherwise I wouldn’t have achieved it.