This week's contributors

This week's top contributors include @rafaelfranca, @sgrif and @matthewd. Big thank you to these 34 contributors who helped improve our framework this week. Hope to see you on the list next time! <3 <3 <3

Detect in-place changes on mutable AR attributes

Good news everyone! Using serialized attributes, or the JSON and HStore columns in postgres will be a lot more straight forward in Rails 4.2.

Up until now, Active Record cannot detect in-place changes to these attributes (e.g. user.settings['favourite_color'] = params[:favourite_color]). As a result, serialized attributes are always re-written to the database regardless of whether there are any changes to its content. On the other hand, in-line changes to JSON and HStore attributes are never re-saved to the database automatically and requires you to jump through a few hoops to get them working.

Well, not anymore. In the last few weeks, @sgrif has been hard at work refactoring the internals of Active Record. Those solid foundation work allowed him to address the dirty serialized attributes problem with relative ease. With this change, these column types now just work like any other scalar attributes.

`rake db:migrate:status` now works with legacy migrations

Do you remember when Rails used to generate migration files with a numeric prefix instead of a timestamp? Like, from wayyyy back? If you upgraded one of those apps to the latest release, you might be surprised that the db:migrate:status rake task no longer works for you. This patch fixed the problem. I suspect that it won't be your only problem though ;)

`has_secure_password` now ensures password is less than 72 characters

If you have been using super-duper long passwords, you might be surprised to find that BCrypt simply ignores anything after the 72nd character. has_secure_password now validates the length of the password is less than that limit. Remember to fit all your anchovies entropies within the first 72 characters of your passwords!

StrongParameters now leaks again

Last week I mentioned that the "memory leak" mentioned in Aaron's blog post has been fixed. Well, the fix was reverted this week. Here @fxn explains why method and the cache is necessary, why the fix is wrong, and why the theoritical possibility of a memory leak is unlikely to matter in real-world usage. See also the new regression test for more details.