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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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:> 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. >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 Haskin 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-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---