On 04/05/2012, at 3:20 PM, Ben Hoskings wrote: > > Ahh, right. I was responding to a slightly different question then :)
Sorry, I should have said it at the very beginning :) > Yep I agree, the join table sounds like the right place for it. I'd just not > use deletion; how about defining a Staffing#deactivate method/action? That totally makes sense. The only reason for all this dance is to preserve the existing interface where Company#users association was used as "active users" only. So that all the forms and other code that relies on it still works. I got the before_destroy to work (forgot to set the :dependent => :destroy). But now there's another problem. 1) company.users << first; company.save! 2) company.users.clear; company.save! ---> the record is "deactivated" as expected 3) company.users << first; company.save! ---> additional record gets inserted, so there is one active and one inactive (violating constraint). > I'd say it's a bad idea to override destroy to do something else like > deactivation -- it's surprising for a #destroy action to not actually remove > the resource. Isn't Model#destroy supposed to be used the same way as Model#save ? It returns truthy/falsy indicating the result. -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" 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/rails-oceania?hl=en.
