# Is there a "touch" method for associated records?

**URL:** <https://www.ruby-forum.com/t/is-there-a-touch-method-for-associated-records/158751>\
**Category:** Rails\
**Created:** [January 27, 2009, 5:42pm UTC](https://www.ruby-forum.com/t/is-there-a-touch-method-for-associated-records/158751 "2009-01-27T17:42:08Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![dmorin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/f0a364/32.png) [@dmorin](https://www.ruby-forum.com/u/dmorin)\
**Post date:** [January 27, 2009, 5:42pm UTC](https://www.ruby-forum.com/t/is-there-a-touch-method-for-associated-records/158751/1 "2009-01-27T17:42:08Z")

</div>

I’m sure I can whip something up to do this, but I’m wondering an  
elegant solution already exists. I will have any number of Registration  
objects coming in through web form, but I wish there to be only one User  
object per unique email address. So far this works fine. So  
Registration belongs\_to User, User has\_many Registrations. (This, by  
the way, is because the site does not have a persistent profile/logged  
in session and thus the same person could fill out the registration form  
multiple times.)

What I’d like is if a person comes in a second time, creates a  
Registration object using an email address that already has an  
associated User, then update the User.updated\_at field. In other words,  
the clean/dirty status of User is based on the most recent Registration  
object that was added.

Does such a feature already exist in the association? I figure I could  
get around it altogether by defining User.updated\_at as the max of  
registrations.updated\_at, but that’s pretty inefficient. My other  
option is just to put in some sort of before\_save filter on  
Registration. But it seems better placed on User - but User isn’t  
technically changing during this operation, right? So I’m not sure  
where I’d hook in.

---

<div class="post-metadata">

**Author:** ![dmorin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/f0a364/32.png) [@dmorin](https://www.ruby-forum.com/u/dmorin)\
**Post date:** [January 27, 2009, 6:35pm UTC](https://www.ruby-forum.com/t/is-there-a-touch-method-for-associated-records/158751/2 "2009-01-27T18:35:34Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![dmorin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/f0a364/32.png) [@dmorin](https://www.ruby-forum.com/u/dmorin)\
**Post date:** [January 27, 2009, 7:40pm UTC](https://www.ruby-forum.com/t/is-there-a-touch-method-for-associated-records/158751/3 "2009-01-27T19:40:53Z")

</div>

Thanks, Denis. The project in question is actually a periodic email  
pull for marketing purposes, which is why I’m taking pains to model a  
“one email per user” expectation, something that current project does  
not have. (I’ll work them into an actual login/password protected  
profile later…) The reason that the updated\_at is important is the  
nature of the marketing message, which will be one of those “Since you  
visited the site 2 days ago…” sorts of things. If a user registered  
for the first time (and created a User object) 3 days ago, but then came  
back in today, registered again (and thus linked to but did not create a  
User object), I would not want to send that message to that person.  
So I need some way to touch the User object at each registration.

I think the option to create a different dedicated field on User, like  
maybe last\_registered\_at, works best - it clearly defines the meaning of  
the field for the next developer who comes along.

D

Denis H. wrote:

> 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