[Rails-core] Feature Request: Track habtm changes
Hey guys, What do you think about tracking habtm changes? Apparently we can't do that because when you change a habtm association it is changed immediately on database instead of waiting the save call (not sure why and the problem may not be because of that). Current behaviour: profile.roles_ids = [] profile.update_attributes(:name = nil, :roles_ids = [...]) = false profile.changes { name = ['Admin', nil] } Expected behaviour: profile.roles_ids = [] profile.update_attributes(:name = nil, :roles_ids = [...]) = false profile.changes { name = ['Admin', nil], :roles_ids = [[], [...]] } Giving some problem context, I have an application that need to audit almost every change and I can track everything using the changes method but habtm changes. We can write a solution like storing the initial state of roles_ids in an after_initialize callback on the model and comparing it on a after_save but I was thinking in a more native solution. What do you think? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
[Rails-core] Re: Feature Request: Track habtm changes
Not sure about how it will impact the application but this is the first shot: https://gist.github.com/sobrinho/6309391 On Thursday, August 22, 2013 12:56:27 PM UTC-3, Gabriel Sobrinho wrote: Hey guys, What do you think about tracking habtm changes? Apparently we can't do that because when you change a habtm association it is changed immediately on database instead of waiting the save call (not sure why and the problem may not be because of that). Current behaviour: profile.roles_ids = [] profile.update_attributes(:name = nil, :roles_ids = [...]) = false profile.changes { name = ['Admin', nil] } Expected behaviour: profile.roles_ids = [] profile.update_attributes(:name = nil, :roles_ids = [...]) = false profile.changes { name = ['Admin', nil], :roles_ids = [[], [...]] } Giving some problem context, I have an application that need to audit almost every change and I can track everything using the changes method but habtm changes. We can write a solution like storing the initial state of roles_ids in an after_initialize callback on the model and comparing it on a after_save but I was thinking in a more native solution. What do you think? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Feature Request: Track habtm changes
On Aug 22, 2013, at 11:56 AM, Gabriel Sobrinho wrote: Hey guys, What do you think about tracking habtm changes? Apparently we can't do that because when you change a habtm association it is changed immediately on database instead of waiting the save call (not sure why and the problem may not be because of that). Current behaviour: profile.roles_ids = [] profile.update_attributes(:name = nil, :roles_ids = [...]) = false profile.changes { name = ['Admin', nil] } Expected behaviour: profile.roles_ids = [] profile.update_attributes(:name = nil, :roles_ids = [...]) = false profile.changes { name = ['Admin', nil], :roles_ids = [[], [...]] } Giving some problem context, I have an application that need to audit almost every change and I can track everything using the changes method but habtm changes. We can write a solution like storing the initial state of roles_ids in an after_initialize callback on the model and comparing it on a after_save but I was thinking in a more native solution. What do you think? Some quick thoughts: * using the _ids= method on has_many doesn't show up in changes either * this could get really expensive if you have a lot of rows on the other end of the HABTM, since you cache the complete list of IDs in memory --Matt Jones -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Backport PR etiquette
Also, if you open a backport PR immediately, and we decide not to accept the patch, it's just clutter. Better to get it actually merged first, then backport. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.