This week in Rails: new query methods, Action Cable enhancements and more!
Posted by imtayadeway, April 1, 2016 @ 12:00 am in News
####
Hey everybody! Tim here reporting from Portland, OR on another solid week for the Rails community. As a protest to April Fools’ typical tomfoolery, this edition is coming to you 100% jape-free. No, really!
Featured
This Week’s Rails Contributors
This week 29 lovely people contributed to Rails, including 5 for the first time! A big Friday Hug goes out to all of them! Feel free to check out the list of current issues for ideas if you’d like to join them ❤️
Improved
Active Record gets a few extra query methods
Ever find yourself writing cumbersome things like User.count.zero?
? You can now use the terser User.none?
, as well as User.one?
and User.empty?
, as these three methods just got added.
The default worker pool size for Action Cable just got lowered considerably!
The author of this revision put it best: “Whack it down from 100 to 4”. This will decrease the number of db connections for most, who probably don’t need so many.
Notifications can now hook into Action Cable
Just as you can subscribe to Action Controller’s #process_action
, so you can now with ActionCable::Channel::Base#perform_action
after this fine addition. Get notified!
Fixed
Prepared statements to have a cache separate from unprepared statements
This subtle bug was fixed this week, wherein a connection that was established with prepared statements enabled could fail if a query that had been previously run was run again with prepared statements disabled. This was because it was hitting the same cache as the prepared statements-enabled query. Prepared statements now have their own cache, which solves the problem. Hurrah!
rails runner now shows the correct command name when run with Spring
Running rails runner
with no arguments or with the --help
flag shows you some information on how to use the runner as a shebang line. Unfortunately, if you were using Spring, it would get the path wrong because Spring changes a variable that relates to the command that was run (bin/rails
). That just got fixed in this revision!
Using rails restart with Puma now works!
Previously, when issuing rails restart
with Puma running, it would fail to bring it up again since Puma was trying to inspect ARGV
to decide how to go about it. The fix involved changing Puma to allow its configuration options to be overridden by Rails. Great job!
Wrapping Up
That’s all for This week in Rails. As always, there are plenty of things we’re not able to cover here, so take a look at the changes yourself.
Until next time!