Given a user without an email, user.errors.details will return {email: [{error: :blank}]}. In some cases, this is more useful than the message {email: ["can't be blank"]} provided by user.errors.messages.
There's a good usage example in this blog post.
Writing drop_table(:users, if_exists: true) in a migration ensures that the migration will run without exceptions, whether or not the "users" table exists.
Calling @users = User.all to list all users works, but you can get better performance by indicating the exact fields you intend to access, for instance with @users = User.select(:name, :email).
The new @users.accessed_fields method will give you the list of fields accessed from the model, so you can easily optimize your queries using .select rather than .all.
Everyone loves a pull request that speeds up Rails,
especially if the performance gain is documented and verifiable.
When in doubt, always use benchmark/ips to provide benchmark results for comparison.
Wrapping up
That's all for This week in Rails. As always, there are more changes than we have room to cover here, but feel free to check them out yourself!
P.S. If you enjoyed this newsletter, why not share it with your friends? :) If you wish to be part of this project please don't hesitate to contact Godfrey – there're a lot of ways you could help make this newsletter more awesome!
