On 15 February 2010 16:45, Max Williams <[email protected]> wrote: > Hi Michael - i kind of expected that kind of reply :)
If you've got special reasons why you think you need to pursue the route you have, it would help if you mention those in your initial post. Anyway... > The reason that i'm doing it in this case is that i've overridden the > set method for one of my foreign keys to do some other stuff after > changing the foreign key. But, it just occurred to me that a better way > to handle that is via a dirty models sort of approach of not getting > involved in the set method but detecting the change instead. What's the > simplest way to do that, do you know? My first thought was "What's stopping you overloading the set method for the associated object? And move your other stuff code into that method." But then I recalled I'd try to do that myself in the past, and hit a brick wall. So I've spent the evening fiddling, and hit the same wall again. Can't seem to get the Rails association magic to fire, as the methods for the associations are created when the class is created. So all I can think is you have two options (one generates smellier code than the other): 1) use the overloaded foreign_key_id method that you are at the moment (which smacks of bypassing the functionality that Rails gives you) and set the model's associated object to nil before doing your stuff (this does work) 2) create a new method (something along the lines of "set_question") which does both the setting of the associated object through the normal "question" method, and does your stuff too. I do wonder if there's a third way that might be a better solution for you, but which depends on the specifics of the "other stuff" that you're doing - it may be that this "other stuff" might be done elsewhere maybe. What's occurring to me now is that because there are two routes to achieve the same thing (changing the associated value through either the association accessors or through the foreign_key_id field; if you change one to do some application magic, you've got to be very careful to *never* call the other method, or else your magic won't happen and your application will do funny stuff. So I'd definitely be looking for the third way! -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
