Hmm, not sure how to get around that. For a moment, I was thinking you could update the active attribute on before_create (similar to the way before_delete works), and then return true. But I'm pretty sure before_create only works on a new record, and would be called in the scope of the "new" User, not the "original" deactivated User.
I'm sure there must be a clean way of handling it, but I can't think of it atm. Too close to beer'o'clock. ;) On Fri, May 4, 2012 at 4:00 PM, Dmytrii Nagirniak <[email protected]> wrote: > On 04/05/2012, at 3:43 PM, Craig Read wrote: > > You might need to use before_create to check that the row doesn't already > exist (in a deactivated state). > > That was my first thought too: > > before_create do > others = Staffing.where(:company_id => company_id, user_id: user_id) > return false if others.any? > end > > but then I'm getting RecordNotSaved exception every time trying to re-add > an object (which is correct). > > I can't see a way of handling it transparently and marry the callbacks. > > > > > On Fri, May 4, 2012 at 3:36 PM, Dmytrii Nagirniak <[email protected]>wrote: > >> 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. >> >> > > > -- > Craig Read > > @Catharz > https://github.com/Catharz > http://stackoverflow.com/users/158893/catharz > > > -- > 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. > > > -- > 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. > -- Craig Read @Catharz https://github.com/Catharz http://stackoverflow.com/users/158893/catharz -- 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.
