reselect, negative enum scopes and more!

Why hello there! Tim here bringing you all the latest and greatest from This Week In Rails.

Negative scopes for enum values

Some sugar around enum values allows you to make negative scopes such as

Post.not_drafted # => where.not(status: :drafted)

New method: reselect

Allows you to change a previously set select statement in the same manner to rewhere and reorder, e.g., :body).reselect(:created_at)

#size fixed when using SELECT DISTINCT

#size_ would ignore the DISTINCT in the select, giving a different result to #count. This is now fixed!

Active Storage’s _blob loading fixed

If you attached a has_one_attachment attachment, you may have found that the attachment’s _blob method would have returned nil. This was fixed by assigning the blob when the attachment is assigned.

22 people contributed to Rails since our last issue; you can see the full list of changes here.

Until next week!

Rails 6.0.0 beta2 released

We’re marching one step closer to the final release of Rails 6 with this second beta. We’ve fixed a bunch of issues and added a few minor features, but the big change is switching to Xavier’s new Zeitwerk library for handling autoloading. It’s a big, structural change to how we require dependencies at runtime, and it should remove a bunch of the legacy warts, and the weird gotchas. Xavier wrote up a long piece on it you should check out.

Otherwise things are much the same as they were with the first beta. I encourage you to read the release notes for that to understand the big picture of 6.0.

You can peruse all the 532 commits we’ve made since the first beta.

We are still kinda on track with our published timeline for the final Rails 6.0 release, so consult that plan for your migration planning, but please do help us already by testing your application on beta2! I’d also encourage anyone with a moderate level of Rails experience to start any new app using beta2, rather than the Rails 5.2.x series. Basecamp and Shopify are both already running Rails 6.0.0.beta2 in production. This isn’t some rickety-shack release.

This release, and all releases leading up to Rails 6.0 final, was shepherded by release manager Rafael França with support by Kasper Timm Hansen.

Thanks again to everyone who keeps working on making Rails better!

Zeitwerk integration in Rails 6 (Beta 2)

The second beta of Rails 6 is about to ship, and includes Zeitwerk integration.

While Rails 6 final is going to have proper documentation about it, this post will help understanding this feature meanwhile.


  • You can now robustly use constant paths in class and module definitions:

    # Autoloading in this class' body matches Ruby semantics now.
    class Admin::UsersController < ApplicationController
      # ...
  • All known use cases of require_dependency have been eliminated.

  • Edge cases in which the autoloaded constant depended on execution order are gone.

  • Autoloading is thread-safe in general, not just for the currently supported use cases with explicit locks like web requests. For example, you can now write multi-threaded scripts to be run by bin/rails runner and they will autoload just fine.

Also, applications get some performance benefits for the same price:

  • Autoloading a constant no longer involves walking autoload paths looking for a relative match in the file system. Zeitwerk does one single pass and autoloads everything using absolute file names. In addition, that single pass descends into subdirectories lazily, only when the namespaces are used.

  • When an application is reloaded due to changes in the file system, code in the autoload paths of engines that were loaded as gems won’t be reloaded anymore.

  • Eager loading eager loads not only the application, but also the code of any gem that is managed by Zeitwerk.

Autoloading modes

Rails 6 ships with two autoloading modes: :zeitwerk and :classic. They are set using the new configuration point config.autoloader.

Zeitwerk mode is the default in Rails 6 for CRuby, automatically enabled by

load_defaults "6.0"

in config/application.rb.

Applications can opt-out putting

config.autoloader = :classic

after the line that loads the defaults.

State of the API

While a first API for Zeitwerk mode is converging, this is still a bit exploratory right now. Please, check the current documentation if your version of Rails is newer than 6.0.0.beta2.

Autoload paths

The configuration point for autoload paths remains config.autoload_paths, and if you push by hand to ActiveSupport::Dependencies.autoload_paths during application initialization, that will also work.


All known use cases of require_dependency have been eliminated. In principle, you should just delete all these calls in the code base. See also the next section about STIs.


Active Record needs to have STI hierarchies fully loaded in order to generate correct SQL. Preloading in Zeitwerk was designed for this use case:

# config/initializers/preload_vehicle_sti.rb

autoloader = Rails.autoloaders.main
sti_leaves = %w(car motorbike truck)

sti_leaves.each do |leaf|

By preloading the leaves of the tree, autoloading will take care of the entire hierarchy upwards following superclasses.

These files are going to be preloaded on boot, and on each reload.


In Zeitwerk mode, Rails.autoloaders is an enumerable that has two Zeitwerk instances called main, and once. The former is the one managing your application, and the latter manages engines loaded as gems, as well as anything in the somewhat unknown config.autoload_once_paths (whose future is not bright). Rails reloads with main, and once is there just for autoloading and eager loading, but does not reload.

Those instances are accessible respectively as


but since Rails.autoloaders is an enumerable, there won’t be too many use cases for direct access, probably.

Inspecting autoloaders activity

If you want to see the autoloaders working, you can throw

Rails.autoloaders.logger = method(:puts)

to config/application.rb after the framework defaults have been set. In addition to a callable, Rails.autoloaders.logger= accepts also anything that responds to debug with arity 1, like regular loggers do.

If you want to see the activity of Zeitwerk for all instances in memory (both Rails’ and others that might be managing gems), you can set

Zeitwerk::Loader.default_logger = method(:puts)

at the top of config/application.rb, before Bundle.require.

Backwards incompatibility

  • For files below the standard concerns directories (like app/models/concerns), Concerns cannot be a namespace. That is, app/models/concerns/geolocatable.rb is expected to define Geolocatable, not Concerns::Geolocatable.

  • Once the application has booted, autoload paths are frozen.

  • Directories in ActiveSupport::Dependencies.autoload_paths that do not exist on boot are ignored. We are referring here to the actual elements of the array only, not to their subdirectories. New subdirectories of autoload paths that existed at boot are picked up just fine as always. (This may change for final.)

  • A file that defines a class or module that acts as a namespace, needs to define the class or module using the class and module keywords. For example, if you have app/models/hotel.rb defining the Hotel class, and app/models/hotel/pricing.rb defining a mixin for hotels, the Hotel class must be defined with class, you cannot do Hotel = { ... } or Hotel = { ... } or anything like that. Those idioms are fine in classes and modules that do not act as namespaces.

  • A file should define only one constant in its namespace (but can define inner ones). So, if app/models/foo.rb defines Foo and also Bar, Bar won’t be reloaded, but reopened when Foo is reloaded. This is strongly discouraged in classic mode anyway though, the convention is to have one single main constant matching the file name. You can have inner constants, so Foo may define an auxiliary internal class Foo::Woo.

Active Record bug fixes, faster Date#advance, and more!

Hello everyone! This is Eugene, with a selection of interesting improvements to Rails merged in the past week.

Don’t load app environment when editing credentials

Support for per-environment credentials is coming in Rails 6.0, but adding a new environment wasn’t always easy: if your application accessed credentials during boot, the credentials:edit command would fail to run, which would in turn prevent you from adding the missing credentials. Oops!

All queries should return correct results even if they include large numbers

When prepared statements are enabled, querying an integer column with an out-of-range value causes an error in the underlying database driver. To work around this issue, Active Record used to refuse to run the query and always return a negative result, e.g. ActiveRecord::RecordNotFound.

This approach worked for simple queries, but gave incorrect results for more complex ones. Out-of-range values are now converted to “impossible” predicates instead (e.g. WHERE 1=0), which allows the query to run without an error while still producing the correct result.

Speaking of large numbers: this pull request, opened 18 months ago, was number 30,000 on the Rails repository. 🎈

Fix year value when casting a multi-parameter time hash

Values stored in TIME columns in the database are mapped to Time objects in Ruby. The latter includes date parts, where the former doesn’t; to deal with this discrepancy, a default date of January 1st, 2000 is always assigned.

When a multi-parameter time value—as generated by the time_select helper—was assigned to an attribute, its year would be set to 1970 instead, producing a different result depending on where the value came from.

With this fix, time attributes have fully joined us in the 21st century. 🖖

Faster and more memory-efficient Date#advance

This method was copying its options hash unnecessarily. Now that it doesn’t, it’s both faster and allocates less memory.

28 people contributed to Rails since our last issue; you can see the full list of changes here.

Until next week!

Rails 6.0.0 beta1, and more

Daniel here, writing from chilly NYC to bring you the latest Rails news.

Rails 6.0.0 beta1

Many thanks to everyone who helped get this amazing release together. It includes Action Text and Action Mailbox, both recently merged into Rails. Try it out today!

New command to change databases

Have you ever created a new Rails app without specifying the database system upfront, then realized you need to switch over from SQLite to PostgreSQL? That change is now as simple as running: bin/rails db:system:change --to=postgresql

Improved multi-db errors

I think we can all appreciate helpful error messages. Many thanks to Eileen for helping us out, and for all of the incredible work to support multiple databases.

Action Cable Testing

The test helpers from the action-cable-testing gem are now fully merged into Rails. Testing your cables has never been easier.

Endless ranges in where conditions

Ruby 2.6 introduced endless ranges. In Rails 6 we will be able to use them in where conditions: features.where(awesomeness: 10..)

Don’t watch your parents

Before this change, if a directory to be watched was not present in the project, Rails would watch that directory’s parent directory instead. In some cases this could lead to watching the entire Rails root directory.

72 people contributed to Rails over the past month. There are still plenty of open issues that could use your help. Will we see your name on the list next week?

Rails 6.0.0 beta1: Action Mailbox, Action Text, Multiple DBs, Parallel Testing, Webpacker by default

The first beta release of Rails 6 is here! It’s absolutely packed with amazing new stuff that we’re so excited to share. There are two major new frameworks – Action Mailbox and Action Text – and two important scalable-by-default upgrades in great multiple database support and parallel testing.

Action Mailbox routes incoming emails to controller-like mailboxes for processing in Rails. It ships with ingresses for Amazon SES, Mailgun, Mandrill, Postmark, and SendGrid. You can also handle inbound mails directly via the built-in Exim, Postfix, and Qmail ingresses. The foundational work on Action Mailbox was done by George Claghorn and yours truly.

Action Text brings rich text content and editing to Rails. It includes the Trix editor that handles everything from formatting to links to quotes to lists to embedded images and galleries. The rich text content generated by the Trix editor is saved in its own RichText model that’s associated with any existing Active Record model in the application. Any embedded images (or other attachments) are automatically stored using Active Storage and associated with the included RichText model. The foundational work on Action Text was done by Sam Stephenson, Javan Makhmali, and yours truly.

The new multiple database support makes it easy for a single application to connect to, well, multiple databases at the same time! You can either do this because you want to segment certain records into their own databases for scaling or isolation, or because you’re doing read/write splitting with replica databases for performance. Either way, there’s a new, simple API for making that happen without reaching inside the bowels of Active Record. The foundational work for multiple-database support was done by Eileen Uchitelle and Aaron Patterson.

With parallel testing support, you can finally take advantage of all those cores in your machine to run big test suites faster. Each testing worker gets its own database and runs in its own thread, so you’re not pegging one CPU to 100% while the other 9 sit idle by (y’all do have a 10-core iMac Pro, right 😂). Hurray! The foundational work for parallel-testing support was done by Eileen Uchitelle and Aaron Patterson.

Webpacker is now the default JavaScript bundler for Rails through the new app/javascript directory. We’re still using the asset pipeline with Sprockets for CSS and static assets, though. The two integrate very nicely and offer the best trade-off of advanced JavaScript features with an it-just-works approach to other assets.

Those are just some of the marque additions, but Rails 6.0 is also packed with minor changes, fixes, and upgrades. Just some I’d call out: Proper Action Cable testing, Action Cable JavaScript rewritten in ES6, protection against DNS rebinding attacks, and per-environment credentials. Also, Rails 6 will require Ruby 2.5.0+ now. You can check out everything in the individual framework CHANGELOG files for the nitty-gritty rundown.

Finally, you should pay attention to Xavier Noria’s new Zeitwerk code loader for Ruby. It didn’t make the integration cut for beta1, but starting with beta2, it’ll be the new autoloader for Rails. Be prepared to say goodbye to any lingering require or require_dependency calls in your code!

We are still roughly on track with our published timeline for the final Rails 6.0 release, so consult that plan for your migration planning, but please do help us already by testing your application on beta1! I’d also encourage anyone with a moderate level of Rails experience to start any new app using beta1, rather than the Rails 5.2.x series. Basecamp is already running Rails 6.0.0.beta1 in production, and both Shopify and GitHub and surely others will follow close thereafter. This isn’t some rickety-shack release.

This release, and all releases leading up to Rails 6.0 final, was shepherded by release manager Rafael França with support by Kasper Timm Hansen.

Thanks again to everyone who keeps working on making Rails better! It’s incredible that we’re still able to keep this intense rate of improvement going after all these years. Rails has never been in fitter shape to help the broadest number of web developers build excellent apps in a way they love. Let joy be sparked!

Timeline for the release of Rails 6.0

We’ve made enough progress towards the vision for Rails 6.0 that it makes sense to share our aspirational timeline for release. “Aspirational” being the key word, more so than “release” 😄. Software rarely ships on time, and we’ve had plenty of aspirational release dates that came and went in the past. But if optimism isn’t part of the fun of open source, then where would we be?

So. This is the timeline as we currently hope to see it:

  • January 15: Beta 1. We’ll merge the two new frameworks, Action Mailbox and Action Text, for this release.
  • February 1: Beta 2. We’ll make sure any other major improvements are included by then.
  • March 1: Release Candidate 1. We go feature complete by here.
  • April 1: Release Candidate 2. This should really be ready to ship, only new blockers will hold us back.
  • April 30: Final release. Ship and celebrate the release of Rails 6.0 at RailsConf 2019!

It always looks so nice and neat when laid out like that, right? Like some serious engineers did some serious engineering to figure this out. And not just a bunch of software writers plotting down their hopes and dreams. But yeah, it’s really the engineering part we went for (no it wasn’t).

Worth noting: Rails 6.0 will require Ruby 2.5+! So you can get ready by making sure you’re already running this version of Ruby. Also note that following the release of Rails 6.0, only Rails 6.x.y and Rails 5.2.x are guaranteed to receive both major and minor security fixes by Rails core. (As always, we may still choose to provide fixes further back, but there’s no guarantee).

As always, please help us make this a reality by running rails/master for new apps and existing ones, if you sport that High Adventure gene (aka no risk of getting fired if you hit a bug). Basecamp 3 is already running rails/master in production, so you know the main branch is at least in pretty good working order!

Our release manager for Rails 6.0 will be Rafael França with backup from Kasper Timm Hansen 🙏

To Rails Six Oh And Beyond! 🚀🚂

George joins Rails Core and Action Mailbox introduced

Hello. This is Wojtek with a short list of news from Rails world.

George joins Rails Core

George Claghorn is now a member of the Rails core team. Welcome George!

Introducing Action Mailbox for Rails 6

Action Mailbox is the brand new framework coming to Rails 6 extracted from Basecamp.

Add ActiveRecord::Base.connected_to?

Another handy method added to support multiple databases.

Fix numericality equality validation on floats

By casting values to BigDecimal comparision on validation is now more precise.

19 people contributed to Rails last week making lot of improvements.
Until next time!

Introducing Action Mailbox for Rails 6

Action Mailbox is the second brand new framework coming to Rails 6 (the first was Action Text). It serves to route incoming emails to controller-like mailboxes for processing in Rails. It ships with ingresses for Amazon SES, Mailgun, Mandrill, and SendGrid. You can also handle inbound mails directly via the Postfix ingress.

The inbound emails are turned into InboundEmail records using Active Record and feature lifecycle tracking, storage of the original email on cloud storage via Active Storage, and responsible data handling with on-by-default incineration. These inbound emails are routed asynchronously using Active Job to one or several dedicated mailboxes, which are capable of interacting directly with the rest of your domain model.

The framework was, like Action Text and Active Storage, extracted from Basecamp 3. We’ve been using a related approach to route everything from forwarded emails to email replies to messages and discussions. After extracting the ideas into Action Mailbox, we reintegrated the framework into Basecamp, and we’ve been running the code we’re sharing today for over a month in production.

Yes, Rails already had an anemic way of receiving emails using Action Mailer, but it was poorly flushed out, lacked cohesion with the task of sending emails, and offered no help on integrating with popular inbound email processing platforms. Action Mailbox supersedes the receiving part of Action Mailer, which will be deprecated in due course.

Rails 6 is getting closer, but it’s still a ways off – we’re hoping to start the beta process in early 2019. Action Mailbox is already in pretty decent shape, though, and you can even use it with Rails 5.2 applications, if you fancy dancing on the wild side. Just be prepared for things changing as we work our way through community review and towards merging it into rails/rails.

The Action Mailbox framework is based off ideas hatched by Jeremy Daer, and this particular implementation was done as a collaboration between yours truly and George Claghorn.

As part of the introduction of Action Mailbox, I plan to record a video showing off the basics in the near future. But the code is ready and somewhat documented for anyone to dive into already. So why sit on a good thing!

Between Action Text and Action Mailbox, Rails 6 is already shaping up to be one of the biggest releases in the history of the framework. And we’re not even done yet! Our plan is tentatively to have a release candidate version ready for RailsConf 2019 in Minneapolis. Please help us make that promise a reality by trying out Action Mailbox!