I can see why you’d want to do this, but I’d leave User.updated_at alone and track this ‘dirtiness’ in some other way.
There’s no reason you can’t do it, but as you say you’d have to accomplish it with an AR callback on Registration, not User.
The default way automatic timestamping is implemented in AR implies that the semantics of the updated_at timestamp are when the object itself was updated. If you change this behavior, you run some risk of a future developer (or yourself in the future) not realizing that updated_at also means the user’s registrations had changed. (As you said: "but User isn’t
technically changing".) You also then lose the ability to know when the User object itself was changed, as opposed to the list of registrations (but maybe you don’t need to be able to make that differentiation).
If I were convinced I needed to do it this way, I would probably add a method User#registrations_changed and have the Registration callback call that, so that this behavior is explicit (and, as you desired, visible in the User class). And would this be better on after_save, not before_save?
And what events in the association would update the user? Adds, deletes, modifies?
My approach on this would also depend on why I needed to have the user’s update date be updated like this; how are you going to use that fact, and could it be done by coming into the association via registrations? E.g. “show me the users whose registrations changed yesterday” could still, I think, be done fairly efficiently even without what you’re proposing.
dwh
Duane Morin wrote: