Let's see an example.

class User  scope :active, -> { where(accepted: true, locked: false) }end>> User.all=> #<ActiveRecord::Relation [#<User id: 1, name: 'Rob', accepted: true, locked: true>#<User id: 2, name: 'Jack', accepted: false, locked: false>#<User id: 3, name: 'Nina', accepted: true, locked: false>#<User id: 4, name: 'Oliver', accepted: false, locked: true>

Now let's query for active and inactive users

>> User.active# SELECT * FROM Users WHERE `accepted` = 1 AND `locked` = 0=> #<ActiveRecord::Relation [#<User id: 3, name: 'Nina', accepted: true, locked: false>]>>> User.active.invert_where# SELECT * FROM Users WHERE NOT (`accepted` = 1 AND `locked` = 0)=> #<ActiveRecord::Relation [#<User id: 1, name: 'Rob', accepted: true, locked: true>#<User id: 2, name: 'Jack', accepted: false, locked: false>#<User id: 4, name: 'Oliver', accepted: false, locked: true>]>

As we can see above, if we use invert_where with multiple attributes, itapplies logical NOR, which is NOT a OR NOT b, to the WHERE clause of thequery. Using DeMorgan's Law, it can also be written as NOT (a AND b) tomatch the second output.

Check out the pull request for moredetails.

In the example below, we want to add a validation that ensures that each item inthe StockItem class has a quantity that ranges from 50 to 100.

class StockItem < ApplicationRecord  validates :quantity, numericality: { greater_than_or_equal_to: 50, less_than_or_equal_to: 100 }endStockItem.create! code: 'Shirt-07', quantity: 40#=> ActiveRecord::RecordInvalid (Validation failed: Quantity must be greater than or equal to 50)

In Rails 6.1, to validate that a numerical value falls within a specific range,we can use the new in: option:

class StockItem < ApplicationRecord  validates :quantity, numericality: { in: 50..100 }endStockItem.create! code: 'Shirt-07', quantity: 40#=> ActiveRecord::RecordInvalid (Validation failed: Quantity must be in 50..100)

Check out the pull request for moredetails on this feature.

Before Rails 6.1

Let's say we are building softwareto manage the inventory of an automobile company.It produces 2 types of vehicles, Car and Motorcycle.Both have name and mileage attributes.

Let's look into at least 2 different solutions to design this system.<br/>

Single Table Inheritance

In this approach, we combine all the attributes of various modelsand store them in a single table.Let's create a Vehicle modelandits corresponding table to store the data of both Car and Motorcycle.

# schema of Vehicle {id: Integer, type: String[car or motorcycle], name: String, mileage: Integer}class Vehicle < ApplicationRecord  # put common logic hereendclass Car < Vehicle  # put car specific code & validationendclass Motorcycle < Vehicle  # put motorcycle-specific code & validationend

This approach fits precisely for this scenariobut when the attributes of the various models differ,it becomes a pain point.Let's say at some point in time we add a bs4_engine boolean columnto track whether a Motorcyle has a bs4_engine or not.In the case of Car, bs4_engine will contain nil.As time passes, a lot of vehicle-specific attributes get addedand the database will be sparsely filled with a lot of nil.

Polymorphic Relations

With polymorphic associations,a model can belong to more than one other model, on a single association.

# schema {name: String, mileage: Integer}class Vehicle < ApplicationRecord  belongs_to :vehicleable, polymorphic: trueend# schema {interior_color: String, adjustable_roof: Boolean}class Car < ApplicationRecord  has_one :vehicle, as: :vehicleableend# schema {bs4_engine: Boolean, tank_color: String}class Motorcycle < ApplicationRecord  has_one :vehicle, as: :vehicleableend

Here, Vehicle is a class that contains common attributes,while Motorcycle and Car store any diverging attributes.This approach fixes the nil values,butto create a Vehicle record we now have to create a Car or Motorcycle first separately.

# creating new records>> bike = Motorcycle.create!( bs4_engine: false, tank_color: '#f2f2f2')#<Motorcycle id: 1, bs4_engine: true, tank_color: '#f2f2f2', created_at: "2021-01-17 ...">>> vehicle = Vehicle.create!(vehicleable: bike, name: 'TS-1987', mileage: 45)#<Vehicle id: 1, vehicleable_type: "Motorcycle", vehicleable_id: 1, name: "TS-1987", mileage: 45, created_at: ..."># query>> b1 = Motorcycle.find(1) #=> <Motorcycle id: 1, bs4_engine: true, tank_color: '#f2f2f2', created_at: "2021-01-17 ...">>> b1.vehicle.name  #=> TS-1987>> b1.vehicle.mileage  #=> 45

Now, let's say, we need to query Vehicles that are Motorcycles,or let's say we want to check whether a Vehicle is a Car or not.For all of these, we will have to write cumbersome logic and queries.

Rails 6.1 delegated_type

Rails 6.1 brings delegated_typewhich fixes the problem discussed above and adds a lot of helper methods.To use it,we just need to replace polymorphic relation with delegated_types.

class Vehicle < ApplicationRecord  delegated_type :vehicleable, types: %w[ Motorcycle Car ]end

That is the only change we need to make to leverage the delegated_type.With this change,we can create both the delegator and delegatee at the same time.

# creating new records>> vehicle1 = Vehicle.create!(vehicleable: Car.new(interior_color: '#fff', adjustable_roof: true), name: 'TS78Z', mileage: 89)#<Vehicle id: 3, vehicleable_type: "Car", vehicleable_id: 2, name: "TS78Z", mileage: 89, created_at: ...">>> vehicle2= Vehicle.create!(vehicleable: Motorcycle.new(bs4_engine: false, tank_color: '#ff00bb'), name: 'BL96', mileage: 45)#<Vehicle id: 4, vehicleable_type: "Motorcycle", vehicleable_id: 5, name: "BL96", mileage: 45, created_at: ..."># Note: Just initializing the delegatee(Car.new/Motorcycle.new) is sufficient.

When it comes to query capabilities, it adds a lot of delegated type convenience methods.

# Get all Vehicles that are Cars>> Vehicle.cars#<ActiveRecord::Relation [#<Vehicle id: 5, vehicleable_type: "Car", vehicleable_id: 1, name: "TS78Z", ...">]># Get all Vehicles that are Motorcycles>> Vehicle.motorcycles#<ActiveRecord::Relation [#<Vehicle id: 1, vehicleable_type: "Motorcycle", vehicleable_id: 1, name: "BL96", ...">]>>> vehicle = Vehicle.find(3)#<Vehicle id: 3, vehicleable_type: "Car", vehicleable_id: 2, name: "TS78Z", mileage: 89, created_at: ..."># check whether a Vehicle is a Car or Motorcycle>> vehicle.car?  #=> true>> vehicle.motorcylce? #=> false# get vehicleable>> vehicle.car # <Car id: 1, adjustable_roof: true, ...>>> vehicle.motorcycle # nil

So, delegated_type can be thought of as sugaron top of polymorphic relations that adds convenience methods.

Check out thepull request to learn more.

Let's take this example of ordering users by the number of times they have logged in.

postgres=> SELECT * from users ORDER BY login_count DESC;       name        | login_count-------------------+------------- Johnny Silverhand |        NULL Jackie Welles     |         202 V                 |           1(3 rows)

This is not useful since most of the time we would want the null values to appear last.

PostgreSQL provides NULLS FIRST and NULLS LAST options for the ORDER BY clause for this use case.

irb> pp User.order("login_count DESC NULLS LAST").        pluck(:name, :login_count)(0.9 ms)  SELECT "users"."name", "users"."login_count" FROM "users"          ORDER BY login_count DESC NULLS LAST=> [["Jackie Welles", 202],   ["V", 1],   ["Johnny Silverhand", nil]]

In Rails 6.1, we can use the new nulls_first or nulls_last methods to construct the same queryusing Arel.

irb> pp User.order(User.arel_table[:login_count].desc.nulls_last).        pluck(:name, :login_count)(0.9 ms)  SELECT "users"."name", "users"."login_count" FROM "users"          ORDER BY login_count DESC NULLS LAST=> [["Jackie Welles", 202],   ["V", 1],   ["Johnny Silverhand", nil]]

The resulting code is slightly more verbose for this simple example. But Arel really shines when programmatically constructing complex SQL queries.

Check out thispull requestfor more details.

What is PostgreSQL Interval Data Type?

PostgreSQL Interval Data Type allows us to store a duration/period of time inyears, months, days, hours, minutes, seconds, etc. It also allows us to performarithmetic operations on that interval.

There are two input formats for interval data. These formats are used to writeinterval values.

1. Verbose format:

  <quantity> <unit> [<quantity> <unit>...] [<direction>]  # Examples:  '2 years ago'  '12 hours 13 minutes ago'  '8 years 7 months 2 days 3 hours'

• quantity can be any number.
• unit can be any granular unit of time in plural or singular form likedays/day, months/month, weeks/week, etc..
• direction can be ago or an empty string.

2. ISO 8601 formats:

P <quantity> <unit> [ <quantity> <unit> ...] [ T [ <quantity> <unit> ...]]

• ISO 8601 format always starts with P.
• quantity and unit before T represents years, months, weeks and days ofan interval.
• quantity and unit after T represents the time-of-day unit.

# ExamplesP1Y1M1D => interval of '1 year 1 month 1 day'P3Y1DT2H => interval of '3 years 1 day 2 hours'P5Y2MT3H2M => interval of '5 years 2 months 3 hours 2 minutes'# NOTE: If `M` appears before `T`,# it is month/months and if it appears after `T`, it signifies minute/minutes.ORP [ years-months-days ] [ T hours:minutes:seconds ]# ExamplesP0012-07-00T00:09:00 => interval of '12 years 7 months 9 minutes'P0000-10-00T10:00:00 => interval of '10 months 10 hours'

Arithmetic operations on interval

We can easily apply addition, subtraction and multiplication operations oninterval data.

'10 hours 10 minutes' + '30 minutes' => '10 hours 40 minutes''10 hours 10 minutes' - '10 minutes' => '10 hours'60 * '10 minute' => '10 hours'

Before Rails 6.1

PostgreSQL interval data type can be used in Rails but Active Record treatsinterval as a string. In order to convert it to an ActiveSupport::Durationobject, we have to manually alter the IntervalStyle of the database toiso_8601 and then parse it as shown below:

execute "ALTER DATABASE <our_database_name> SET IntervalStyle = 'iso_8601'"ActiveSupport::Duration.parse(the_iso_8601_formatted_string)

Rails 6.1

Rails 6.1 adds built-in support for the PostgreSQL interval data type. Itautomatically converts interval to an ActiveSupport::Duration object whenfetched from a database. When a record containing the interval field is saved,it is serialized to an ISO 8601 formatted duration string.

The following example illustrates how it can be used now:

# db/migrate/20201109111850_create_seminars.rbclass CreateSeminars < ActiveRecord::Migration[6.1]  def change    create_table :seminars do |t|      t.string :name      t.interval :duration      t.timestamps    end  endend# app/models/seminar.rbclass Seminar < ApplicationRecord  attribute :duration, :intervalend>> seminar = Seminar.create!(name: 'RubyConf', duration: 5.days)>> seminar=> #<Event id: 1, name: "RubyConf", duration: 5 days, created_at: ...>>> seminar.duration=> 5 days>> seminar.duration.class=> ActiveSupport::Duration>> seminar.duration.iso8601=> "P5D"# ISO 8601 strings can also be provided as interval's value>> seminar = Seminar.create!(name: 'GopherConIndia', duration: 'P5DT7H6S')>> seminar=> #<Event id: 2, name: "GopherConIndia", duration: 5 days, 7 hours, and 6 seconds, created_at: ...># Invalid values to interval are written as NULL in the database.>> seminar = Seminar.create!(name: 'JSConf', duration: '3 days')>> seminar=> #<Event id: 3, name: "JSConf", duration: nil, created_at: ...>

If we want to keep the old behaviour where interval is treated as a string, weneed to add the following in the model.

# app/models/seminar.rbclass Seminar < ApplicationRecord  attribute :duration, :stringend

If the attribute is not set in the model, it will throw the followingdeprecation warning.

DEPRECATION WARNING: The behavior of the `:interval` type will be changing in Rails 6.2to return an `ActiveSupport::Duration` object. If you'd like to keepthe old behavior, you can add this line to Event model:  attribute :duration, :stringIf you'd like the new behavior today, you can add this line:  attribute :duration, :interval

Check out thecommitfor more details.

In development, the config/storage/development.yml filewill take precedence over the config/storage.yml file.Similarly, in production, the config/storage/production.yml filewill take precedence.

If an environment-specific configuration is not present,Rails will fall back to the configuration declared in config/storage.yml.

Why was it needed?

Before Rails 6.1, all storage services were defined in one file,each environment could set its preferred service in config.active_storage.service,and that service would be used for all attachments.

Now we can override the default application-wide storage servicefor any attachment, like this:

class User < ApplicationModel  has_one_attached :avatar, service: :amazon_s3end

And we can declare a custom amazon_s3 service in the config/storage.yml file:

amazon_s3:  service: S3  bucket: "..."  access_key_id: "..."  secret_access_key: "..."

But we are still using the same service for storing avatarsin both production and development environments.

To use a separate service per environment,Rails allows the creation of configuration files for each.

How do we do that?

Let's change the service to something more generic in the User model:

class User < ApplicationModel  has_one_attached :avatar, service: :store_avatarsend

And add some environment configurations:

For production we'll add config/storage/production.yml:

store_avatars:  service: S3  bucket: "..."  access_key_id: "..."  secret_access_key: "..."

And for development we'll add config/storage/development.yml:

store_avatars:  service: Disk  root: <%= Rails.root.join("storage") %>

This will ensure that Rails will store the avatarsdifferently per environment.

Check out thepull requestto learn more.

The inverse_of option, both in belongs_to and has_many isused to specify the name of the inverse association.

Let's see an example.

class Author < ApplicationRecord  has_many :books, inverse_of: :authorendclass Book < ApplicationRecord  belongs_to :author, inverse_of: :booksend

Before Rails 6.1

has_many to belongs_to inversing

irb(main):001:0> author = Author.newirb(main):002:0> book = author.books.buildirb(main):003:0> author == book.author=> true

In the above code,first we created the author and thena book instance through the has_many association.

In line 3,we traverse the object chainback to the author using the belongs_to association methodon the book instance.

belongs_to to has_many inversing

irb(main):001:0> book = Book.newirb(main):002:0> author = book.build_authorirb(main):003:0> author.books=> #<ActiveRecord::Associations::CollectionProxy []>

In the above case,we created the book instance and thenwe created the author instance usingthe method added by belongs_to association.

But when we tried to traverse the object chainthrough the has_many association,we got an empty collectioninstead of one with the book instance.

After changes in Rails 6.1

The belongs_to inversing can now be traversedin the same way as the has_many inversing.

irb(main):001:0> book = Book.newirb(main):002:0> author = book.build_authorirb(main):003:0> author.books=> #<ActiveRecord::Associations::CollectionProxy [#<Book id: nil, author_id: nil, created_at: nil, updated_at: nil>]>

Here we get the collection with the book instanceinstead of an empty collection.

We can also verify using a test.

class InverseTest < ActiveSupport::TestCase  def test_book_inverse_of_author    author = Author.new    book = author.books.build    assert_equal book.author, author  end  def test_author_inverse_of_book    book = Book.new    author = book.build_author    assert_includes author.books, book  endend

In previous Rails versions, the test cases would fail.

# Running:.FFailure:InverseTest#test_author_inverse_of_bookExpected #<ActiveRecord::Associations::CollectionProxy []> to include #<Book id: nil, author_id: nil, created_at: nil, updated_at: nil>.Finished in 0.292532s, 6.8369 runs/s, 10.2553 assertions/s.2 runs, 3 assertions, 1 failures, 0 errors, 0 skips

In Rails 6.1, both the tests will pass.

# Running:..Finished in 0.317668s, 6.2959 runs/s, 9.4438 assertions/s.2 runs, 3 assertions, 0 failures, 0 errors, 0 skips

Check out thispull requestfor more details.

Before Rails 6.1, only the following tasks worked on a specific database.

• rails db:migrate:primary
• rails db:create:primary
• rails db:drop:primary

But some tasks that could be applied to a specific database were missing. Let'scheckout an example.

Before Rails 6.1, running a top level migration on a multi-database project,dumped the schema for all the configured databases, but if a database specificmigration was run, the schema was not dumped. And there were no tasks tomanually dump the schema of a specific database.

> rails db:schema:dump:primaryrails aborted!Don't know how to build task `db:schema:dump:primary` (See the list of available tasks with `rails --tasks`)Did you mean? db:schema:dump

Therefore, in Rails 6.1, the following database specific tasks were introduced.

• rails db:schema:dump:primary
• rails db:schema:load:primary
• rails db:test:prepare:primary

Check out the pull request for moredetails.

strict_loading mode is an optional setup and it helps in finding N+1queries.

Let's consider the following example.

class Article < ApplicationRecord  has_many :commentsendclass Comment < ApplicationRecord  belongs_to :articleend

Mark a record for strict_loading

When strict_loading mode is enabled for a record then its associations have tobe eager loaded otherwise Rails raisesActiveRecord::StrictLoadingViolationError.

Let's see this use case by setting strict_loading mode for an articlerecord.

2.7.2 :001 > article = Article.strict_loading.first  Article Load (0.2ms)  SELECT "articles".* FROM "articles" ORDER BY "articles"."id" ASC LIMIT ?  [["LIMIT", 1]] => #<Article id: 1, title: "First article", content: "First content", created_at: "2020-12-01 07:23:38.446867000 +0000", updated_at: "2020-12-01 07:23:38.446867000 +0000">2.7.2 :002 > article.strict_loading? => true2.7.2 :003 > article.commentsTraceback (most recent call last):ActiveRecord::StrictLoadingViolationError (`Comment` called on `Article` is marked for strict_loading and cannot be lazily loaded.)

strict_loading mode forces us to eager load the associated comments by raisingthe ActiveRecord::StrictLoadingViolationError error.

Let's fix the strict_loading violation error.

2.7.2 :004 > article = Article.includes(:comments).strict_loading.first  Article Load (0.7ms)  SELECT "articles".* FROM "articles" ORDER BY "articles"."id" ASC LIMIT ?  [["LIMIT", 1]]  Comment Load (0.2ms)  SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = ?  [["article_id", 1]] => #<Article id: 1, title: "First article", content: "First content", created_at: "2020-12-01 07:23:38.446867000 +0000", updated_at: "2020-12-01 07:23:38.446867000 +0000">2.7.2 :005 > article.comments => #<ActiveRecord::Associations::CollectionProxy [#<Comment id: 1, desc: "Great article", article_id: 1, created_at: "2020-12-01 07:23:58.832869000 +0000", updated_at: "2020-12-01 07:23:58.832869000 +0000">  , #<Comment id: 2, desc: "Well written", article_id: 1, created_at: "2020-12-01 07:24:02.853376000 +0000", updated_at: "2020-12-01 07:24:02.853376000 +0000">]>

strict_loading mode on article record automatically sets strict_loadingmode for all the associated comments as well.

Let's verify this in Rails console.

2.7.2 :006 > article.comments.all?(&:strict_loading?) => true

Mark an association for strict_loading

strict_loading mode can be set up for a specific association.

Let's update our example to see strict_loading in action when it is passed asan option to associations.

class Article < ApplicationRecord  has_many :comments, strict_loading: trueendclass Comment < ApplicationRecord  belongs_to :articleend

Let's verify this in Rails console.

2.7.2 :001 > article = Article.first  Article Load (0.2ms)  SELECT "articles".* FROM "articles" ORDER BY "articles"."id" ASC LIMIT ?  [["LIMIT", 1]] => #<Article id: 1, title: "First article", content: "First content", created_at: "2020-12-01 07:23:38.446867000 +0000", updated_at: "2020-12-01 07:23:38.446867000 +0000">2.7.2 :002 > article.strict_loading? => false2.7.2 :003 > article.commentsTraceback (most recent call last):ActiveRecord::StrictLoadingViolationError (`comments` called on `Article` is marked for strict_loading and cannot be lazily loaded.)2.7.2 :004 > article = Article.includes(:comments).first  Article Load (0.2ms)  SELECT "articles".* FROM "articles" ORDER BY "articles"."id" ASC LIMIT ?  [["LIMIT", 1]]  Comment Load (0.2ms)  SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = ?  [["article_id", 1]] => #<Article id: 1, title: "First article", content: "First content", created_at: "2020-12-01 07:23:38.446867000 +0000", updated_at: "2020-12-01 07:23:38.446867000 +0000">2.7.2 :005 > article.comments => #<ActiveRecord::Associations::CollectionProxy [#<Comment id: 1, desc: "Great article", article_id: 1, created_at: "2020-12-01 07:23:58.832869000 +0000", updated_at: "2020-12-01 07:23:58.832869000 +0000">, #<Comment id: 2, desc: "Well written", article_id: 1, created_at: "2020-12-01 07:24:02.853376000 +0000", updated_at: "2020-12-01 07:24:02.853376000 +0000">]>

Configure strict_loading per model

We can set strict_loading_by_default option per model to mark all of itsrecords and associations for strict_loading.

Let's update our example to set strict_loading_by_default for the Articlemodel.

class Article < ApplicationRecord  self.strict_loading_by_default = true  has_many :commentsendclass Comment < ApplicationRecord  belongs_to :articleend

Let's verify this setting in the Article model.

2.7.2 :001 > article = Article.includes(:comments).first  Article Load (0.2ms)  SELECT "articles".* FROM "articles" ORDER BY "articles"."id" ASC LIMIT ?  [["LIMIT", 1]]  Comment Load (0.2ms)  SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = ?  [["article_id", 1]] => #<Article id: 1, title: "First article", content: "First content", created_at: "2020-12-01 07:23:38.446867000 +0000", updated_at: "2020-12-01 07:23:38.446867000 +0000">2.7.2 :002 > article.strict_loading? => true2.7.2 :003 > article.comments.all?(&:strict_loading?) => false2.7.2 :004 > article.comments => #<ActiveRecord::Associations::CollectionProxy [#<Comment id: 1, desc: "Great article", article_id: 1, created_at: "2020-12-01 07:23:58.832869000 +0000", updated_at: "2020-12-01 07:23:58.832869000 +0000">, #<Comment id: 2, desc: "Well written", article_id: 1, created_at: "2020-12-01 07:24:02.853376000 +0000", updated_at: "2020-12-01 07:24:02.853376000 +0000">]>

Make strict_loading default across all models

We can make strict_loading default across all models by adding the followingline to the Rails configuration file.

config.active_record.strict_loading_by_default = true

Configure strict_loading violations to show only in logs

By default, associations marked for strict loading always raiseActiveRecord::StrictLoadingViolationError for lazy loading.

However, we may prefer to log such violations in our production environmentinstead of raising errors.

We can add the following line to the environment configuration file.

config.active_record.action_on_strict_loading_violation = :log

Check out pull requests #37400,#38541,#39491 and#40511 for more details.

default_scope -> { where(...) }, all_queries: true

Consider the Article class below.

class Article  default_scope -> { where(organization_id: Current.organization_id) }end@article.update title: "Hello World"@article.delete

The update and delete methods would generate SQL queries as shown below. Aswe can see that default_scope is missing from these queries.

UPDATE "articles" SET "title" = $1 WHERE "articles"."id" = $2 [["title", "Hello World"], ["id", 146]]DELETE FROM "articles" WHERE "articles"."id" = $1  [["id", 146]]

In Rails 6.1 we can solve this problem by passing all_queries: true to thedefault_scope.

class Article  default_scope -> { where(organization_id: Current.organization_id) }, all_queries: trueend

Then the generated SQL changes to this:

UPDATE "articles" SET "title" = $1 WHERE "articles"."id" = $2 AND "articles"."organization_id" = $3  [["title", "Hello World"], ["id", 146], ["organization_id", 314]]DELETE FROM "articles" WHERE "articles"."id" = $1 AND "articles"."organization_id" = $2  [["id", 146], ["organization_id", 314]]

Ability to make default_scopes applicable to all queries is particularly usefulin the case of multi-tenanted applications, where an organization_id orrepository_id is added to the tables to support sharding.

Check out the pull request for moredetails on this feature.

Let's see an example of it.

class Account < ApplicationRecord  has_many :users, -> { joins(:contact).where.not(contact_id: nil) }end

This will return all users with contacts.If we rephrase that sentence then we can say that "this will return all users who are associated with contacts".

Let's see how we can do the same with the new associated method.

class Account < ApplicationRecord  has_many :users, -> { where.associated(:contact) }end

Now we can see that the usage of associated decreases some of the syntactic noise we saw in the first example. This method is essentially a syntactic sugar over the inner_joins(:contact).

Check out thepull requestfor more details.

What are impossible "camelCase" inflections?

TheRails Inflectoris part of the ActiveSupport module,and it comes shipped with patterns to transform Ruby strings.This library is responsible for pluralization and/or singularizationof strings.

The Inflector tries its best to provide the desired result givena string. But sometimes, with certain words, it can't provide saythe pluralized version out of the box.

Let's say for example the string is DSL.The desired plural form is DSLs.But the Inflector gets confused on what exactly isthe desired plural form or more accurately whatexactly is the underscore resource nameandit used to generate inconsistent class names.

Before Rails 6.1

Let's try out the following example.

bundle exec rails g scaffold DSL field

In the output we can see that the controller filenameis ds_ls_controller.rbandthe controller class name is:

class DsLsController < ApplicationController

And the routes file is populated with:

resources :dsls

You see the problem right?

The generated route :dslsexpects a DslsController controller but the controller generated is DsLsController.This will lead to a routing error.

How Rails 6.1 solves this problem?

The Rails team decided that it would be better toterminate the generation process with an errorrather than generating classes that are internally inconsistent.

Thus Rails now raises an error in the following two scenarioswhere the casing is impossible to be inflected:

The first case is when "camelCased" model name is passed to a generator.The second case is when the full round trip from pluralize to singularize does notmatch with the original singular value. Rails checks for the following condition.

name.pluralize.underscore.singularize != name.underscore.singularize

We can try out the same example that we did in the previous sectionand it will provide the following output:

Rails cannot recover the underscored form from its camelcase form 'DSL'.Please use an underscored name instead, either 'dsl' or 'ds_l'.Or set up custom inflection rules for this noun before running the generator in config/initializers/inflections.rb.

This allows the developers to either rephrase the resource namewith an underscored name from the very beginning itselforfollow the suggestion, that is to create a custom inflection.

Creating a custom inflection

ActiveSupport::Inflector provides us with the inflections methodin order to create our own custom inflections.This method can even accept an optional locale,which comes in handy when we are writinginflection rules for languages other than :en,which is the default locale.

You can have a detailed look into the inflection methods overhere.

Let's try to make the above example workandget the desired underscore namefor the string DSL.Were dealing with an irregular inflection.Thus we can make use of the irregular method,which takes two arguments:the singular and the plural form of the word as strings.

Let's just add the custom inflection intoconfig/initializers/inflections.rb:

# We provide the string in lowercase formatActiveSupport::Inflector.inflections(:en) do |inflect| inflect.irregular 'dsl', 'dsls'end

Voila!That's it.

Now if we run rails g scaffold DSL,we will be able to get the correct file and class names.

Check out thepull requestandthe issuefor more details.

Let's consider the following example.

class Team < ApplicationRecord  has_many :players, dependent: :destroy_asyncendclass Player < ApplicationRecord  belongs_to :teamend

Now, if we call the destroy method on an instance of class Team Rails wouldenqueue an asynchronous job to delete the associated players records.

We can verify this asynchronous job with the following test case.

class TeamTest < ActiveSupport::TestCase  include ActiveJob::TestHelper  test "destroying a record destroys the associations using a background job" do    team = Team.create!(name: "Portugal", manager: "Fernando Santos")    player1 = Player.new(name: "Bernardo Silva")    player2 = Player.new(name: "Diogo Jota")    team.players << [player1, player2]    team.save!    team.destroy    assert_enqueued_jobs 1    assert_difference -> { Player.count }, -2 do      perform_enqueued_jobs    end  endendFinished in 0.232213s, 4.3064 runs/s, 8.6128 assertions/s.1 runs, 2 assertions, 0 failures, 0 errors, 0 skips

Alternatively, this enqueue behavior can also be demonstrated inrails console.

irb(main):011:0> team.destroy  TRANSACTION (0.1ms)  begin transaction  Player Load (0.6ms)  SELECT "players".* FROM "players" WHERE "players"."team_id" = ?  [["team_id", 6]]Enqueued ActiveRecord::DestroyAssociationAsyncJob (Job ID: 4df07c2d-f55b-48c9-8c20-545b086adca2) to Async(active_record_destroy) with arguments: {:owner_model_name=>"Team", :owner_id=>6, :association_class=>"Player", :association_ids=>[1, 2], :association_primary_key_column=>:id, :ensuring_owner_was_method=>nil}Performed ActiveRecord::DestroyAssociationAsyncJob (Job ID: 4df07c2d-f55b-48c9-8c20-545b086adca2) from Async(active_record_destroy) in 34.5ms

However, this behaviour is inconsistent and the destroy_async option shouldnot be used when the association is backed by foreign key constraints in thedatabase.

Let us consider another example.

CASE: With a simple foreign key on the team_id column in place.

irb(main):015:0> team.destroy  TRANSACTION (0.1ms)  begin transaction  Player Load (0.1ms)  SELECT "players".* FROM "players" WHERE "players"."team_id" = ?  [["team_id", 7]]Enqueued ActiveRecord::DestroyAssociationAsyncJob (Job ID: 69e51e5f-5b59-4095-92db-90aab73a7f65) to Async(default) with arguments: {:owner_model_name=>"Team", :owner_id=>7, :association_class=>"Player", :association_ids=>[1], :association_primary_key_column=>:id, :ensuring_owner_was_method=>nil}  Team Destroy (0.9ms)  DELETE FROM "teams" WHERE "teams"."id" = ?  [["id", 7]]  TRANSACTION (1.1ms)  rollback transactionPerforming ActiveRecord::DestroyAssociationAsyncJob (Job ID: 69e51e5f-5b59-4095-92db-90aab73a7f65) from Async(default) enqueued at 2021-01-03T21:10:21Z with arguments: {:owner_model_name=>"Team", :owner_id=>7, :association_class=>"Player", :association_ids=>[1], :association_primary_key_column=>:id, :ensuring_owner_was_method=>nil}Traceback (most recent call last):        1: from (irb):15ActiveRecord::InvalidForeignKey (SQLite3::ConstraintException: FOREIGN KEY constraint failed)

An exception is raised by Rails and the record is not destroyed.

CASE: With a cascading foreign key using on_delete: :cascade

Here, even though ActiveRecord::DestroyAssociationAsyncJob would run tosuccessful completion, the associated players records would already be deletedinside the same transaction block destroying the team record, and it wouldskip any destroy callbacks like before_destroy, after_destroy orafter_commit on: :destroy.

This makes using destroy_async redundant in such a case.

Check out the pull request for moredetails.

Let's check out an example of extracting values from a User model instance.

class User < ApplicationRecord  def full_name    "#{self.first_name} #{self.last_name}"  endend >> user = User.new(first_name: 'Era', last_name: 'Das' , email: 'era@gmail.com')=> User id: nil, first_name: "Era", last_name: "Das", created_at: nil, updated_at: nil, email: "era@gmail.com", password_digest: nil

Before Rails 6.1

As shown below using values_at for full_name, which is a method, returnsnil.

>> user.attributes.values_at("first_name", "full_name")=> ["Era", nil]

After changes in Rails 6.1

Rails 6.1 added the values_at method on Active Record which returns an arraycontaining the values associated with the given methods.

>> user.values_at("first_name", "full_name")=> ["Era", "Era Das"]

Check out the pull request for moredetails.

Without the environment variable

> bundle exec rake db:createCreated database 'app_name_development'Created database 'app_name_test'

With the environment variable

> SKIP_TEST_DATABASE=true bundle exec rake db:createCreated database 'app_name_development'

As we can see in the first example, both a development and a test databasewere created, which is unexpected when directly invoking db:create. Oneobvious solution to this problem is to force the development environment toonly create a development database. However this solution will breakbin/setup as mentioned inthis commit.Hence the need for an environment variable to skip test database creation.

Check out the pull request for moredetails.

> User.find_each{|user| puts user.inspect}User Load (0.4ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT ?  [["LIMIT", 1000]]

Rails 6.1 now supports ORDER BY id for ActiveRecord batch processing methodslike find_each, find_in_batches, and in_batches. This would allow us toretrieve the records in ascending or descending order of ID.

> User.find_each(order: :desc){|user| puts user.inspect}User Load (0.4ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" DESC LIMIT ?  [["LIMIT", 1000]]

> User.find_in_batches(order: :desc) do |users|>   users.each do |user|>     puts user.inspect>   end> endUser Load (0.3ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" DESC LIMIT ?  [["LIMIT", 1000]]

> User.in_batches(order: :desc) do |users|>   users.each do |user|>     puts user.inspect>   end> end(0.2ms)  SELECT "users"."id" FROM "users" ORDER BY "users"."id" DESC LIMIT ?  [["LIMIT", 1000]]User Load (0.2ms)  SELECT "users".* FROM "users" WHERE "users"."id" = ?  [["id", 101]]

Points to remember:

• The ORDER BY clause only works with the primary key column.
• Valid values for the ORDER BY clause are [:asc,:desc] and it's casesensitive. If we use caps or title case (like DESC or Asc) then we'll getan ArgumentError as shown below.

> User.find_in_batches(order: :DESC) do |users|>   users.each do |user|>     puts user.inspect>   end> endTraceback (most recent call last):        2: from (irb):5        1: from (irb):6:in `rescue in irb_binding'ArgumentError (unknown keyword: :order)

Check out the pull request for moredetails.

Before Rails 6.1, executing rake db:schema:dump would dump db/schema.rbfile. And executing rake db:structure:dump would dump db/structure.sql file.

Rails provides config.active_record.schema_format setting for which the validvalues are :ruby or :sql. However, since there are specific tasks fordb:structure and db:schema this value was not really being used.

Changes in Rails 6.1

In Rails 6.1 the Rails team decided to combine the two different tasks into asingle task. In Rails 6.1 rails db:structure:dump andrails db:structure:load have been deprecated and the following message wouldbe shown.

Using `bin/rails db:structure:dump` is deprecated and will be removed in Rails 6.2. Configure the format using `config.active_record.schema_format = :sql` to use `structure.sql` and run `bin/rails db:schema:dump` instead.

Now Rails will start taking into the account value set forconfig.active_record.schema_format.

rails db:schema:dump and rails db:schema:load would do the right thing basedon the value set for config.active_record.schema_format.

Check out the pull request for moredetails on this.

If we want to omit some of the features then we needed to skip them like this.

# before Rails 6.1$ rails new tiny_app    --skip-action-cable    --skip-action-mailer    --skip-action-mailbox    --skip-action-text    --skip-active-storage    --skip-bootsnap    --skip-javascript    --skip-spring    --skip-system-test    --skip-webpack-install    --skip-turbolinks

Before Rails 6.1 it was not possible to skip things like active_job andjbuilder.

Rails 6.1

Rails 6.1 added a new option --minimal.

$ rails new tiny_app --minimal

All the following are excluded from this minimal Rails application.

• action_cable
• action_mailbox
• action_mailer
• action_text
• active_job
• active_storage
• bootsnap
• jbuilder
• spring
• system_tests
• turbolinks
• webpack

We can bundle webpack in this minimal app like this.

$ rails new tiny_app --minimal webpack=react

Database option can also be passed.

$ rails new tiny_app --minimal --database postgresql webpack=react

Check out the pull request for moredetails on this.

Prior to this change, on executing db:rollback Rails used to rollback thelatest migration from the primary database. If we passed on a [:NAME] optionalong with to specify the database, we used to get an error. Check out theissue for more details.

Rails 6.0.0

> rails db:rollback:secondaryrails aborted!Don't know how to build task `db:rollback:secondary` (See the list of available tasks with `rails --tasks`)Did you mean?  db:rollback

Staring with Rails 6.1, we need to pass the database name along withdb:rollback:[NAME] otherwise a RuntimeError is raised.

Rails 6.1.0

> rails db:rollbackrails aborted!You're using a multiple database application. To use `db:migrate:rollback` you must run the namespaced task with a VERSION. Available tasks are db:migrate:rollback:primary and db:migrate:rollback:secondary.> rails db:rollback:primary== 20200731130500 CreateTeams: reverting ======================================-- drop_table(:teams)   -> 0.0060s== 20200731130500 CreateTeams: reverted (0.0104s) =============================

Check out the pull request for moredetails on this.

return / break

>> Post.transaction do>>   @post.update(post_params)>>>>   break # or return>> end# => TRANSACTION (0.1ms)  begin transaction# => DEPRECATION WARNING: Using `return`, `break` or `throw` to exit a transaction block is# => deprecated without replacement. If the `throw` came from# => `Timeout.timeout(duration)`, pass an exception class as a second# => argument so it doesn't use `throw` to abort its block. This results# => in the transaction being committed, but in the next release of Rails# => it will rollback.# => TRANSACTION (0.8ms)  commit transaction

throw

>> Timeout.timeout(1) do>>   Post.transaction do>>     @post.update(post_params)>>>>     sleep 3 # simulate slow request>>   end>> end# => TRANSACTION (0.1ms)  begin transaction# => DEPRECATION WARNING: Using `return`, `break` or `throw` to exit a transaction block is# => deprecated without replacement. If the `throw` came from# => `Timeout.timeout(duration)`, pass an exception class as a second# => argument so it doesn't use `throw` to abort its block. This results# => in the transaction being committed, but in the next release of Rails# => it will rollback.# => TRANSACTION (1.6ms)  commit transaction# => Completed 500 Internal Server Error in 1022ms (ActiveRecord: 3.2ms | Allocations: 9736)# => Timeout::Error (execution expired)

Here, even when the error was thrown the transaction is committed. This issomething which is going to change in the future versions.

This is done because currently, when a transaction block is wrapped inTimeout.timeout(duration) i.e. without second argument(an exception class)then it uses throw to exit the transaction.

Solution

>> Timeout.timeout(1, Timeout::Error) do>>   Post.transaction do>>     @post.update(post_params)>>>>     sleep 3 # simulate slow request>>   end>> end# => TRANSACTION (0.1ms)  begin transaction# => TRANSACTION (0.7ms)  rollback transaction# => Timeout::Error (execution expired)

Check out the pull request for moredetails on this.

class Person < ApplicationRecordconnects_to database: { writing: :crm }end

As the application grows, more and more models start sharing the same database.Now a lot of models may contain connects_to call to the same database.

class Person < ApplicationRecordconnects_to database: { writing: :crm }endclass Order < ApplicationRecordconnects_to database: { writing: :crm }endclass Sale < ApplicationRecordconnects_to database: { writing: :crm }end

In order to avoid the duplication, we can create an abstract class connecting toa database and manually inherit all other models from that class. This couldlook like this.

class CrmRecord < ApplicationRecordself.abstract_class = trueconnects_to database: { writing: :crm }endclass Person < CrmRecordendclass Order < CrmRecordendclass Sale < CrmRecordend

Rails 6.1

Before Rails 6.1 we had no choice but to create that abstract class manually.Rails 6.1 allows us to generate an abstract class when we are generating a modelusing scaffold.

$ rails g scaffold Person name:string --database=crm

It creates an abstract class with the database's name appended with Record.The generated model automatically inherits from the new abstract class.

# app/models/users_record.rbclass CrmRecord < ApplicationRecordself.abstract_class = trueconnects_to database: { writing: :crm }end# app/models/admin.rbclass Person < CrmRecordend

If the abstract class already exists, it is not created again. We can also usean existing class as the abstract class by passing parent option to thescaffold command.

$ rails g scaffold Customer name:string --database=crm --parent=PrimaryRecord

This skips generating CrmRecord class as we have specified Rails to usePrimaryRecord abstract class as its parent.

Check out the pull request for moredetails on this.

Rails 6.1

Add the following line in development.rb file to enable this feature.

config.action_view.annotate_rendered_view_with_filenames = true

Now the rendered HTML will contain comment indicating the beginning and end ofeach template.

Here is an example.

In the image we can see the begin and end for each of the templates. Ithelps a lot in debugging webpages to find out which template is rendered. Checkout the pull request for moredetails on this.

Let's take an example of blog posts with status and category columns.

class Post < ApplicationRecord  enum status: %i[draft reviewed published]  enum category: { rails: "Rails", react: "React" }end

Before Rails 6.1, defaults for enum attributes can be configured by applyingdefault on the database level.

class AddColumnStatusToPosts < ActiveRecord::Migration[6.0]  def change    add_column :posts, :status, :integer, default: 0    add_column :posts, :category, :string, default: "Rails"  endend

After Rails 6.1, defaults for enum attributes can be configured directly in thePost model using _default option.

class Post < ApplicationRecord  enum status: %i[draft reviewed published], _default: "draft"  enum category: { rails: "Rails", react: "React" }, _default: "Rails"end

The new approach to set enum defaults has following advantages. Let's understandkeeping the context of Post model with category as an example.

• When the category default value changes from Rails to React. We have toadd a new migration in Rails 6 and previous versions to update the databasecolumn default.
• Let say the default value for post category(i.e: Rails) is removed from theenum from Post model. Rails 6 and previous versions wouldn't throw anexception and continue to work without setting any default value. Rails 6.1with new syntax would raise an exception.

Check out the pull request for moredetails on this.

Rails 6.1 adds support to comparison operator in the where clause. The fourcomparison operators supported are:

• Greater than (>).
• Greater than equal to (>=).
• Less than (<).
• Less than equal to (<=).

The comparison operator is also supported by the finder methods in ActiveRecordwhich internally uses where clause, for example: find_by, destroy_by,delete_by.

The new style for comparisons has to follow advantages:

• The where clause with the comparison operator doesn't raise an exceptionwhen ActiveRecord::Relation uses ambiguous column name.
• The where clause with the comparison operator handle proper precision of thedatabase columns.

Before Rails 6.1, to add a condition with comparison in where clause, we had toadd raw SQL notation.

Rails 6.0.0

>> Post.where("DATE(published_at) > DATE(?)", Date.today)# => <ActiveRecord::Relation [...]>>> Post.find_by("likes < ?", 10)# => <ActiveRecord::Relation [...]># Following query on execution would raise exception.>> Post.joins(:comments).where("likes > 10")# => ambiguous column name: id

Rails 6.1.0

>> Post.where("published_at >": Date.today)# => <ActiveRecord::Relation [...]>>> Post.find_by("likes <": 10)# => <ActiveRecord::Relation [...]># Following query on execution would NOT raise exception.>> Post.joins(:comments).where("likes >": 10)# => <ActiveRecord::Relation [...]>

Check out the pull request for moredetails on this.

Active Storage generates variants on demand by downloading the originalimage. The image is transformed into a variant and is stored to the third partyservices like S3.

When a request to fetch a variant for an Active Storage object is made, Railschecks if the variant is already been processed and is already available on S3or not. But to do so Rails has to make a call to find out if the variant isavailable on S3. This extra call adds to the latency.

Active Storage has to wait until the image variant check call is completedbecause S3 might not return the image when a GET request is made due to eventualconsistency.This way Rails avoid downloading a broken image from S3 and uploading brokenimage variant to S3 in case the variant is not present.

In Rails 6.1, Active Storage tracks the presence of the variant in the database.This change avoids unnecessary variant presence remote request made to the S3and directly fetches or generates a image variant.

In Rails 6.1, the configuration to allow variant tracking in the database is bydefault set to true.

config.active_storage.track_variants: true

Check out the pull request for moredetails on this.

Before Rails 6.1, conditional classes were added by using conditionalstatements. Let's take an example of adding an active class to navigation linkbased on the current page.

Rails 6.0.0

<li class="<%= current_page?(dashboards_path) ? 'active' : '' %>">  <%= link_to "Home", dashboards_path %></li>

Rails 6.1.0

>> class_names(active: current_page?(dashboards_path))=> "active"# Default classes can be added with conditional classes>> class_names('navbar', { active: current_page?(dashboards_path) })=> "navbar active"# class_names helper rejects empty strings, nil, false arguments.>> class_names(nil, '', false, 'navbar', {active: current_page?(dashboards_path)})=> "navbar active"

<li class="<%= class_names(active: current_page?(dashboards_path)) %>">  <%= link_to "Home", dashboards_path %></li>

Check out the pull request for moredetails on this.

Before Rails 6.1, to retrieve the previous attribute value, we used*_previous_change orprevious_changes.

Here is how it can be used.

Rails 6.0.0

>> user = User.new=> #<User id: nil, name: nil, email: nil, created_at: nil, updated_at: nil>>> user.name = "Sam"# *_was returns the original value. In this example, the name was initially nil.>> user.name_was=> nil>> user.save!# After save, the original value is set to "Sam". To retrieve the# previous value, we had to use `previous_changes`.>> user.previous_changes[:name]=> [nil, "Sam"]

Rails 6.1.0

>> user = User.find_by(name: "Sam")=> #<User id: 1, name: "Sam", email: nil, created_at: "2019-10-14 17:53:06", updated_at: "2019-10-14 17:53:06">>> user.name = "Nick">> user.name_was=> "Sam">> user.save!>> user.previous_changes[:name]=> ["Sam", "Nick"]# *_previously_was returns the previous value.>> user.name_previously_was=> "Sam"# After reload, all the dirty tracking# attributes is reset.>> user.reload>> user.name_previously_was=> nil

Check out the pull request for moredetails on this.