ApplicationRecord documentation pass

This is a pass over the documentation which fills the missing gaps of
`ApplicationRecord`.

[ci skip]

13 files changed, 163 insertions, 162 deletions

diff --git a/guides/source/action_view_overview.md b/guides/source/action_view_overview.md
index 4b0e9bff7c..d9037674ca 100644
--- a/guides/source/action_view_overview.md
+++ b/guides/source/action_view_overview.md
@@ -990,11 +990,11 @@ Returns `select` and `option` tags for the collection of existing return values
 Example object structure for use with this method:
 
 ```ruby
-class Article < ActiveRecord::Base
+class Article < ApplicationRecord
   belongs_to :author
 end
 
-class Author < ActiveRecord::Base
+class Author < ApplicationRecord
   has_many :articles
   def name_with_initial
     "#{first_name.first}. #{last_name}"
@@ -1026,11 +1026,11 @@ Returns `radio_button` tags for the collection of existing return values of `met
 Example object structure for use with this method:
 
 ```ruby
-class Article < ActiveRecord::Base
+class Article < ApplicationRecord
   belongs_to :author
 end
 
-class Author < ActiveRecord::Base
+class Author < ApplicationRecord
   has_many :articles
   def name_with_initial
     "#{first_name.first}. #{last_name}"
@@ -1062,11 +1062,11 @@ Returns `check_box` tags for the collection of existing return values of `method
 Example object structure for use with this method:
 
 ```ruby
-class Article < ActiveRecord::Base
+class Article < ApplicationRecord
   has_and_belongs_to_many :authors
 end
 
-class Author < ActiveRecord::Base
+class Author < ApplicationRecord
   has_and_belongs_to_many :articles
   def name_with_initial
     "#{first_name.first}. #{last_name}"
@@ -1099,12 +1099,12 @@ Returns a string of `option` tags, like `options_from_collection_for_select`, bu
 Example object structure for use with this method:
 
 ```ruby
-class Continent < ActiveRecord::Base
+class Continent < ApplicationRecord
   has_many :countries
   # attribs: id, name
 end
 
-class Country < ActiveRecord::Base
+class Country < ApplicationRecord
   belongs_to :continent
   # attribs: id, name, continent_id
 end
diff --git a/guides/source/active_support_core_extensions.md b/guides/source/active_support_core_extensions.md
index 06c5476d45..0cb34aa8bc 100644
--- a/guides/source/active_support_core_extensions.md
+++ b/guides/source/active_support_core_extensions.md
@@ -397,7 +397,7 @@ The method `with_options` provides a way to factor out common options in a serie
 Given a default options hash, `with_options` yields a proxy object to a block. Within the block, methods called on the proxy are forwarded to the receiver with their options merged. For example, you get rid of the duplication in:
 
 ```ruby
-class Account < ActiveRecord::Base
+class Account < ApplicationRecord
   has_many :customers, dependent: :destroy
   has_many :products,  dependent: :destroy
   has_many :invoices,  dependent: :destroy
@@ -408,7 +408,7 @@ end
 this way:
 
 ```ruby
-class Account < ActiveRecord::Base
+class Account < ApplicationRecord
   with_options dependent: :destroy do |assoc|
     assoc.has_many :customers
     assoc.has_many :products
@@ -568,7 +568,7 @@ NOTE: Defined in `active_support/core_ext/module/aliasing.rb`.
 Model attributes have a reader, a writer, and a predicate. You can alias a model attribute having the corresponding three methods defined for you in one shot. As in other aliasing methods, the new name is the first argument, and the old name is the second (one mnemonic is that they go in the same order as if you did an assignment):
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   # You can refer to the email column as "login".
   # This can be meaningful for authentication code.
   alias_attribute :login, :email
@@ -876,7 +876,7 @@ The macro `delegate` offers an easy way to forward methods.
 Let's imagine that users in some application have login information in the `User` model but name and other data in a separate `Profile` model:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   has_one :profile
 end
 ```
@@ -884,7 +884,7 @@ end
 With that configuration you get a user's name via their profile, `user.profile.name`, but it could be handy to still be able to access such attribute directly:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   has_one :profile
 
   def name
@@ -896,7 +896,7 @@ end
 That is what `delegate` does for you:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   has_one :profile
 
   delegate :name, to: :profile
diff --git a/guides/source/association_basics.md b/guides/source/association_basics.md
index c3bac320eb..d83dda7228 100644
--- a/guides/source/association_basics.md
+++ b/guides/source/association_basics.md
@@ -19,10 +19,10 @@ Why Associations?
 In Rails, an _association_ is a connection between two Active Record models. Why do we need associations between models? Because they make common operations simpler and easier in your code. For example, consider a simple Rails application that includes a model for customers and a model for orders. Each customer can have many orders. Without associations, the model declarations would look like this:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
 end
 
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
 end
 ```
 
@@ -45,11 +45,11 @@ end
 With Active Record associations, we can streamline these - and other - operations by declaratively telling Rails that there is a connection between the two models. Here's the revised code for setting up customers and orders:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, dependent: :destroy
 end
 
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer
 end
 ```
@@ -89,7 +89,7 @@ In the remainder of this guide, you'll learn how to declare and use the various
 A `belongs_to` association sets up a one-to-one connection with another model, such that each instance of the declaring model "belongs to" one instance of the other model. For example, if your application includes customers and orders, and each order can be assigned to exactly one customer, you'd declare the order model this way:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer
 end
 ```
@@ -122,7 +122,7 @@ end
 A `has_one` association also sets up a one-to-one connection with another model, but with somewhat different semantics (and consequences). This association indicates that each instance of a model contains or possesses one instance of another model. For example, if each supplier in your application has only one account, you'd declare the supplier model like this:
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account
 end
 ```
@@ -164,7 +164,7 @@ end
 A `has_many` association indicates a one-to-many connection with another model. You'll often find this association on the "other side" of a `belongs_to` association. This association indicates that each instance of the model has zero or more instances of another model. For example, in an application containing customers and orders, the customer model could be declared like this:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders
 end
 ```
@@ -197,17 +197,17 @@ end
 A `has_many :through` association is often used to set up a many-to-many connection with another model. This association indicates that the declaring model can be matched with zero or more instances of another model by proceeding _through_ a third model. For example, consider a medical practice where patients make appointments to see physicians. The relevant association declarations could look like this:
 
 ```ruby
-class Physician < ActiveRecord::Base
+class Physician < ApplicationRecord
   has_many :appointments
   has_many :patients, through: :appointments
 end
 
-class Appointment < ActiveRecord::Base
+class Appointment < ApplicationRecord
   belongs_to :physician
   belongs_to :patient
 end
 
-class Patient < ActiveRecord::Base
+class Patient < ApplicationRecord
   has_many :appointments
   has_many :physicians, through: :appointments
 end
@@ -255,17 +255,17 @@ WARNING: Automatic deletion of join models is direct, no destroy callbacks are t
 The `has_many :through` association is also useful for setting up "shortcuts" through nested `has_many` associations. For example, if a document has many sections, and a section has many paragraphs, you may sometimes want to get a simple collection of all paragraphs in the document. You could set that up this way:
 
 ```ruby
-class Document < ActiveRecord::Base
+class Document < ApplicationRecord
   has_many :sections
   has_many :paragraphs, through: :sections
 end
 
-class Section < ActiveRecord::Base
+class Section < ApplicationRecord
   belongs_to :document
   has_many :paragraphs
 end
 
-class Paragraph < ActiveRecord::Base
+class Paragraph < ApplicationRecord
   belongs_to :section
 end
 ```
@@ -284,17 +284,17 @@ For example, if each supplier has one account, and each account is associated wi
 supplier model could look like this:
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account
   has_one :account_history, through: :account
 end
 
-class Account < ActiveRecord::Base
+class Account < ApplicationRecord
   belongs_to :supplier
   has_one :account_history
 end
 
-class AccountHistory < ActiveRecord::Base
+class AccountHistory < ApplicationRecord
   belongs_to :account
 end
 ```
@@ -331,11 +331,11 @@ end
 A `has_and_belongs_to_many` association creates a direct many-to-many connection with another model, with no intervening model. For example, if your application includes assemblies and parts, with each assembly having many parts and each part appearing in many assemblies, you could declare the models this way:
 
 ```ruby
-class Assembly < ActiveRecord::Base
+class Assembly < ApplicationRecord
   has_and_belongs_to_many :parts
 end
 
-class Part < ActiveRecord::Base
+class Part < ApplicationRecord
   has_and_belongs_to_many :assemblies
 end
 ```
@@ -372,11 +372,11 @@ If you want to set up a one-to-one relationship between two models, you'll need
 The distinction is in where you place the foreign key (it goes on the table for the class declaring the `belongs_to` association), but you should give some thought to the actual meaning of the data as well. The `has_one` relationship says that one of something is yours - that is, that something points back to you. For example, it makes more sense to say that a supplier owns an account than that an account owns a supplier. This suggests that the correct relationships are like this:
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account
 end
 
-class Account < ActiveRecord::Base
+class Account < ApplicationRecord
   belongs_to :supplier
 end
 ```
@@ -409,11 +409,11 @@ NOTE: Using `t.integer :supplier_id` makes the foreign key naming obvious and ex
 Rails offers two different ways to declare a many-to-many relationship between models. The simpler way is to use `has_and_belongs_to_many`, which allows you to make the association directly:
 
 ```ruby
-class Assembly < ActiveRecord::Base
+class Assembly < ApplicationRecord
   has_and_belongs_to_many :parts
 end
 
-class Part < ActiveRecord::Base
+class Part < ApplicationRecord
   has_and_belongs_to_many :assemblies
 end
 ```
@@ -421,17 +421,17 @@ end
 The second way to declare a many-to-many relationship is to use `has_many :through`. This makes the association indirectly, through a join model:
 
 ```ruby
-class Assembly < ActiveRecord::Base
+class Assembly < ApplicationRecord
   has_many :manifests
   has_many :parts, through: :manifests
 end
 
-class Manifest < ActiveRecord::Base
+class Manifest < ApplicationRecord
   belongs_to :assembly
   belongs_to :part
 end
 
-class Part < ActiveRecord::Base
+class Part < ApplicationRecord
   has_many :manifests
   has_many :assemblies, through: :manifests
 end
@@ -446,15 +446,15 @@ You should use `has_many :through` if you need validations, callbacks or extra a
 A slightly more advanced twist on associations is the _polymorphic association_. With polymorphic associations, a model can belong to more than one other model, on a single association. For example, you might have a picture model that belongs to either an employee model or a product model. Here's how this could be declared:
 
 ```ruby
-class Picture < ActiveRecord::Base
+class Picture < ApplicationRecord
   belongs_to :imageable, polymorphic: true
 end
 
-class Employee < ActiveRecord::Base
+class Employee < ApplicationRecord
   has_many :pictures, as: :imageable
 end
 
-class Product < ActiveRecord::Base
+class Product < ApplicationRecord
   has_many :pictures, as: :imageable
 end
 ```
@@ -501,7 +501,7 @@ end
 In designing a data model, you will sometimes find a model that should have a relation to itself. For example, you may want to store all employees in a single database model, but be able to trace relationships such as between manager and subordinates. This situation can be modeled with self-joining associations:
 
 ```ruby
-class Employee < ActiveRecord::Base
+class Employee < ApplicationRecord
   has_many :subordinates, class_name: "Employee",
                           foreign_key: "manager_id"
 
@@ -567,7 +567,7 @@ Associations are extremely useful, but they are not magic. You are responsible f
 When you declare a `belongs_to` association, you need to create foreign keys as appropriate. For example, consider this model:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer
 end
 ```
@@ -599,11 +599,11 @@ WARNING: The precedence between model names is calculated using the `<=>` operat
 Whatever the name, you must manually generate the join table with an appropriate migration. For example, consider these associations:
 
 ```ruby
-class Assembly < ActiveRecord::Base
+class Assembly < ApplicationRecord
   has_and_belongs_to_many :parts
 end
 
-class Part < ActiveRecord::Base
+class Part < ApplicationRecord
   has_and_belongs_to_many :assemblies
 end
 ```
@@ -646,11 +646,11 @@ By default, associations look for objects only within the current module's scope
 ```ruby
 module MyApplication
   module Business
-    class Supplier < ActiveRecord::Base
+    class Supplier < ApplicationRecord
        has_one :account
     end
 
-    class Account < ActiveRecord::Base
+    class Account < ApplicationRecord
        belongs_to :supplier
     end
   end
@@ -662,13 +662,13 @@ This will work fine, because both the `Supplier` and the `Account` class are def
 ```ruby
 module MyApplication
   module Business
-    class Supplier < ActiveRecord::Base
+    class Supplier < ApplicationRecord
        has_one :account
     end
   end
 
   module Billing
-    class Account < ActiveRecord::Base
+    class Account < ApplicationRecord
        belongs_to :supplier
     end
   end
@@ -680,14 +680,14 @@ To associate a model with a model in a different namespace, you must specify the
 ```ruby
 module MyApplication
   module Business
-    class Supplier < ActiveRecord::Base
+    class Supplier < ApplicationRecord
        has_one :account,
         class_name: "MyApplication::Billing::Account"
     end
   end
 
   module Billing
-    class Account < ActiveRecord::Base
+    class Account < ApplicationRecord
        belongs_to :supplier,
         class_name: "MyApplication::Business::Supplier"
     end
@@ -700,11 +700,11 @@ end
 It's normal for associations to work in two directions, requiring declaration on two different models:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders
 end
 
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer
 end
 ```
@@ -722,11 +722,11 @@ c.first_name == o.customer.first_name # => false
 This happens because `c` and `o.customer` are two different in-memory representations of the same data, and neither one is automatically refreshed from changes to the other. Active Record provides the `:inverse_of` option so that you can inform it of these relations:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, inverse_of: :customer
 end
 
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, inverse_of: :orders
 end
 ```
@@ -781,7 +781,7 @@ When you declare a `belongs_to` association, the declaring class automatically g
 In all of these methods, `association` is replaced with the symbol passed as the first argument to `belongs_to`. For example, given the declaration:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer
 end
 ```
@@ -848,7 +848,7 @@ Does the same as `create_association` above, but raises `ActiveRecord::RecordInv
 While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the `belongs_to` association reference. Such customizations can easily be accomplished by passing options and scope blocks when you create the association. For example, this association uses two such options:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, dependent: :destroy,
     counter_cache: true
 end
@@ -877,7 +877,7 @@ If you set the `:autosave` option to `true`, Rails will save any loaded members
 If the name of the other model cannot be derived from the association name, you can use the `:class_name` option to supply the model name. For example, if an order belongs to a customer, but the actual name of the model containing customers is `Patron`, you'd set things up this way:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, class_name: "Patron"
 end
 ```
@@ -887,10 +887,10 @@ end
 The `:counter_cache` option can be used to make finding the number of belonging objects more efficient. Consider these models:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer
 end
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders
 end
 ```
@@ -898,10 +898,10 @@ end
 With these declarations, asking for the value of `@customer.orders.size` requires making a call to the database to perform a `COUNT(*)` query. To avoid this call, you can add a counter cache to the _belonging_ model:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, counter_cache: true
 end
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders
 end
 ```
@@ -918,10 +918,10 @@ the `counter_cache` declaration instead of `true`. For example, to use
 `count_of_orders` instead of `orders_count`:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, counter_cache: :count_of_orders
 end
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders
 end
 ```
@@ -949,7 +949,7 @@ WARNING: You should not specify this option on a `belongs_to` association that i
 By convention, Rails assumes that the column used to hold the foreign key on this model is the name of the association with the suffix `_id` added. The `:foreign_key` option lets you set the name of the foreign key directly:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, class_name: "Patron",
                         foreign_key: "patron_id"
 end
@@ -965,11 +965,11 @@ of its tables. The `:primary_key` option allows you to specify a different colum
 For example, given we have a `users` table with `guid` as the primary key. If we want a separate `todos` table to hold the foreign key `user_id` in the `guid` column, then we can use `primary_key` to achieve this like so:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   self.primary_key = 'guid' # primary key is guid and not id
 end
 
-class Todo < ActiveRecord::Base
+class Todo < ApplicationRecord
   belongs_to :user, primary_key: 'guid'
 end
 ```
@@ -982,11 +982,11 @@ When we execute `@user.todos.create` then the `@todo` record will have its
 The `:inverse_of` option specifies the name of the `has_many` or `has_one` association that is the inverse of this association. Does not work in combination with the `:polymorphic` options.
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, inverse_of: :customer
 end
 
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, inverse_of: :orders
 end
 ```
@@ -1000,11 +1000,11 @@ Passing `true` to the `:polymorphic` option indicates that this is a polymorphic
 If you set the `:touch` option to `true`, then the `updated_at` or `updated_on` timestamp on the associated object will be set to the current time whenever this object is saved or destroyed:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, touch: true
 end
 
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders
 end
 ```
@@ -1012,7 +1012,7 @@ end
 In this case, saving or destroying an order will update the timestamp on the associated customer. You can also specify a particular timestamp attribute to update:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, touch: :orders_updated_at
 end
 ```
@@ -1031,7 +1031,7 @@ object won't be validated. By default, this option is set to `false`.
 There may be times when you wish to customize the query used by `belongs_to`. Such customizations can be achieved via a scope block. For example:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, -> { where active: true },
                         dependent: :destroy
 end
@@ -1049,7 +1049,7 @@ You can use any of the standard [querying methods](active_record_querying.html)
 The `where` method lets you specify the conditions that the associated object must meet.
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, -> { where active: true }
 end
 ```
@@ -1059,16 +1059,16 @@ end
 You can use the `includes` method to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models:
 
 ```ruby
-class LineItem < ActiveRecord::Base
+class LineItem < ApplicationRecord
   belongs_to :order
 end
 
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer
   has_many :line_items
 end
 
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders
 end
 ```
@@ -1076,16 +1076,16 @@ end
 If you frequently retrieve customers directly from line items (`@line_item.order.customer`), then you can make your code somewhat more efficient by including customers in the association from line items to orders:
 
 ```ruby
-class LineItem < ActiveRecord::Base
+class LineItem < ApplicationRecord
   belongs_to :order, -> { includes :customer }
 end
 
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer
   has_many :line_items
 end
 
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders
 end
 ```
@@ -1133,7 +1133,7 @@ When you declare a `has_one` association, the declaring class automatically gain
 In all of these methods, `association` is replaced with the symbol passed as the first argument to `has_one`. For example, given the declaration:
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account
 end
 ```
@@ -1197,7 +1197,7 @@ Does the same as `create_association` above, but raises `ActiveRecord::RecordInv
 While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the `has_one` association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this association uses two such options:
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account, class_name: "Billing", dependent: :nullify
 end
 ```
@@ -1229,7 +1229,7 @@ If you set the `:autosave` option to `true`, Rails will save any loaded members
 If the name of the other model cannot be derived from the association name, you can use the `:class_name` option to supply the model name. For example, if a supplier has an account, but the actual name of the model containing accounts is `Billing`, you'd set things up this way:
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account, class_name: "Billing"
 end
 ```
@@ -1255,7 +1255,7 @@ unallowed `NULL` value.
 By convention, Rails assumes that the column used to hold the foreign key on the other model is the name of this model with the suffix `_id` added. The `:foreign_key` option lets you set the name of the foreign key directly:
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account, foreign_key: "supp_id"
 end
 ```
@@ -1267,11 +1267,11 @@ TIP: In any case, Rails will not create foreign key columns for you. You need to
 The `:inverse_of` option specifies the name of the `belongs_to` association that is the inverse of this association. Does not work in combination with the `:through` or `:as` options.
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account, inverse_of: :supplier
 end
 
-class Account < ActiveRecord::Base
+class Account < ApplicationRecord
   belongs_to :supplier, inverse_of: :account
 end
 ```
@@ -1301,7 +1301,7 @@ If you set the `:validate` option to `true`, then associated objects will be val
 There may be times when you wish to customize the query used by `has_one`. Such customizations can be achieved via a scope block. For example:
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account, -> { where active: true }
 end
 ```
@@ -1318,7 +1318,7 @@ You can use any of the standard [querying methods](active_record_querying.html)
 The `where` method lets you specify the conditions that the associated object must meet.
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account, -> { where "confirmed = 1" }
 end
 ```
@@ -1328,16 +1328,16 @@ end
 You can use the `includes` method to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models:
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account
 end
 
-class Account < ActiveRecord::Base
+class Account < ApplicationRecord
   belongs_to :supplier
   belongs_to :representative
 end
 
-class Representative < ActiveRecord::Base
+class Representative < ApplicationRecord
   has_many :accounts
 end
 ```
@@ -1345,16 +1345,16 @@ end
 If you frequently retrieve representatives directly from suppliers (`@supplier.account.representative`), then you can make your code somewhat more efficient by including representatives in the association from suppliers to accounts:
 
 ```ruby
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_one :account, -> { includes :representative }
 end
 
-class Account < ActiveRecord::Base
+class Account < ApplicationRecord
   belongs_to :supplier
   belongs_to :representative
 end
 
-class Representative < ActiveRecord::Base
+class Representative < ApplicationRecord
   has_many :accounts
 end
 ```
@@ -1415,7 +1415,7 @@ When you declare a `has_many` association, the declaring class automatically gai
 In all of these methods, `collection` is replaced with the symbol passed as the first argument to `has_many`, and `collection_singular` is replaced with the singularized version of that symbol. For example, given the declaration:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders
 end
 ```
@@ -1582,7 +1582,7 @@ Does the same as `collection.create` above, but raises `ActiveRecord::RecordInva
 While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the `has_many` association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this association uses two such options:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, dependent: :delete_all, validate: false
 end
 ```
@@ -1615,7 +1615,7 @@ If you set the `:autosave` option to `true`, Rails will save any loaded members
 If the name of the other model cannot be derived from the association name, you can use the `:class_name` option to supply the model name. For example, if a customer has many orders, but the actual name of the model containing orders is `Transaction`, you'd set things up this way:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, class_name: "Transaction"
 end
 ```
@@ -1639,7 +1639,7 @@ Controls what happens to the associated objects when their owner is destroyed:
 By convention, Rails assumes that the column used to hold the foreign key on the other model is the name of this model with the suffix `_id` added. The `:foreign_key` option lets you set the name of the foreign key directly:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, foreign_key: "cust_id"
 end
 ```
@@ -1651,11 +1651,11 @@ TIP: In any case, Rails will not create foreign key columns for you. You need to
 The `:inverse_of` option specifies the name of the `belongs_to` association that is the inverse of this association. Does not work in combination with the `:through` or `:as` options.
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, inverse_of: :customer
 end
 
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer, inverse_of: :orders
 end
 ```
@@ -1670,7 +1670,7 @@ hold the `guid` column value as the foreign key and not `id`
 value. This can be achieved like this:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   has_many :todos, primary_key: :guid
 end
 ```
@@ -1700,7 +1700,7 @@ If you set the `:validate` option to `false`, then associated objects will not b
 There may be times when you wish to customize the query used by `has_many`. Such customizations can be achieved via a scope block. For example:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, -> { where processed: true }
 end
 ```
@@ -1723,7 +1723,7 @@ You can use any of the standard [querying methods](active_record_querying.html)
 The `where` method lets you specify the conditions that the associated object must meet.
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :confirmed_orders, -> { where "confirmed = 1" },
     class_name: "Order"
 end
@@ -1732,7 +1732,7 @@ end
 You can also set conditions via a hash:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :confirmed_orders, -> { where confirmed: true },
                               class_name: "Order"
 end
@@ -1749,7 +1749,7 @@ The `extending` method specifies a named module to extend the association proxy.
 The `group` method supplies an attribute name to group the result set by, using a `GROUP BY` clause in the finder SQL.
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :line_items, -> { group 'orders.id' },
                         through: :orders
 end
@@ -1760,16 +1760,16 @@ end
 You can use the `includes` method to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders
 end
 
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer
   has_many :line_items
 end
 
-class LineItem < ActiveRecord::Base
+class LineItem < ApplicationRecord
   belongs_to :order
 end
 ```
@@ -1777,16 +1777,16 @@ end
 If you frequently retrieve line items directly from customers (`@customer.orders.line_items`), then you can make your code somewhat more efficient by including line items in the association from customers to orders:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, -> { includes :line_items }
 end
 
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :customer
   has_many :line_items
 end
 
-class LineItem < ActiveRecord::Base
+class LineItem < ApplicationRecord
   belongs_to :order
 end
 ```
@@ -1796,7 +1796,7 @@ end
 The `limit` method lets you restrict the total number of objects that will be fetched through an association.
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :recent_orders,
     -> { order('order_date desc').limit(100) },
     class_name: "Order",
@@ -1812,7 +1812,7 @@ The `offset` method lets you specify the starting offset for fetching objects vi
 The `order` method dictates the order in which associated objects will be received (in the syntax used by an SQL `ORDER BY` clause).
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, -> { order "date_confirmed DESC" }
 end
 ```
@@ -1833,7 +1833,7 @@ Use the `distinct` method to keep the collection free of duplicates. This is
 mostly useful together with the `:through` option.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   has_many :readings
   has_many :articles, through: :readings
 end
@@ -1927,7 +1927,7 @@ When you declare a `has_and_belongs_to_many` association, the declaring class au
 In all of these methods, `collection` is replaced with the symbol passed as the first argument to `has_and_belongs_to_many`, and `collection_singular` is replaced with the singularized version of that symbol. For example, given the declaration:
 
 ```ruby
-class Part < ActiveRecord::Base
+class Part < ApplicationRecord
   has_and_belongs_to_many :assemblies
 end
 ```
@@ -2081,7 +2081,7 @@ Does the same as `collection.create`, but raises `ActiveRecord::RecordInvalid` i
 While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the `has_and_belongs_to_many` association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this association uses two such options:
 
 ```ruby
-class Parts < ActiveRecord::Base
+class Parts < ApplicationRecord
   has_and_belongs_to_many :assemblies, -> { readonly },
                                        autosave: true
 end
@@ -2103,7 +2103,7 @@ By convention, Rails assumes that the column in the join table used to hold the
 TIP: The `:foreign_key` and `:association_foreign_key` options are useful when setting up a many-to-many self-join. For example:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   has_and_belongs_to_many :friends,
       class_name: "User",
       foreign_key: "this_user_id",
@@ -2120,7 +2120,7 @@ If you set the `:autosave` option to `true`, Rails will save any loaded members
 If the name of the other model cannot be derived from the association name, you can use the `:class_name` option to supply the model name. For example, if a part has many assemblies, but the actual name of the model containing assemblies is `Gadget`, you'd set things up this way:
 
 ```ruby
-class Parts < ActiveRecord::Base
+class Parts < ApplicationRecord
   has_and_belongs_to_many :assemblies, class_name: "Gadget"
 end
 ```
@@ -2130,7 +2130,7 @@ end
 By convention, Rails assumes that the column in the join table used to hold the foreign key pointing to this model is the name of this model with the suffix `_id` added. The `:foreign_key` option lets you set the name of the foreign key directly:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   has_and_belongs_to_many :friends,
       class_name: "User",
       foreign_key: "this_user_id",
@@ -2151,7 +2151,7 @@ If you set the `:validate` option to `false`, then associated objects will not b
 There may be times when you wish to customize the query used by `has_and_belongs_to_many`. Such customizations can be achieved via a scope block. For example:
 
 ```ruby
-class Parts < ActiveRecord::Base
+class Parts < ApplicationRecord
   has_and_belongs_to_many :assemblies, -> { where active: true }
 end
 ```
@@ -2174,7 +2174,7 @@ You can use any of the standard [querying methods](active_record_querying.html)
 The `where` method lets you specify the conditions that the associated object must meet.
 
 ```ruby
-class Parts < ActiveRecord::Base
+class Parts < ApplicationRecord
   has_and_belongs_to_many :assemblies,
     -> { where "factory = 'Seattle'" }
 end
@@ -2183,7 +2183,7 @@ end
 You can also set conditions via a hash:
 
 ```ruby
-class Parts < ActiveRecord::Base
+class Parts < ApplicationRecord
   has_and_belongs_to_many :assemblies,
     -> { where factory: 'Seattle' }
 end
@@ -2200,7 +2200,7 @@ The `extending` method specifies a named module to extend the association proxy.
 The `group` method supplies an attribute name to group the result set by, using a `GROUP BY` clause in the finder SQL.
 
 ```ruby
-class Parts < ActiveRecord::Base
+class Parts < ApplicationRecord
   has_and_belongs_to_many :assemblies, -> { group "factory" }
 end
 ```
@@ -2214,7 +2214,7 @@ You can use the `includes` method to specify second-order associations that shou
 The `limit` method lets you restrict the total number of objects that will be fetched through an association.
 
 ```ruby
-class Parts < ActiveRecord::Base
+class Parts < ApplicationRecord
   has_and_belongs_to_many :assemblies,
     -> { order("created_at DESC").limit(50) }
 end
@@ -2229,7 +2229,7 @@ The `offset` method lets you specify the starting offset for fetching objects vi
 The `order` method dictates the order in which associated objects will be received (in the syntax used by an SQL `ORDER BY` clause).
 
 ```ruby
-class Parts < ActiveRecord::Base
+class Parts < ApplicationRecord
   has_and_belongs_to_many :assemblies,
     -> { order "assembly_name ASC" }
 end
@@ -2271,7 +2271,7 @@ Association callbacks are similar to normal callbacks, but they are triggered by
 You define association callbacks by adding options to the association declaration. For example:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, before_add: :check_credit_limit
 
   def check_credit_limit(order)
@@ -2285,7 +2285,7 @@ Rails passes the object being added or removed to the callback.
 You can stack callbacks on a single event by passing them as an array:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders,
     before_add: [:check_credit_limit, :calculate_shipping_charges]
 
@@ -2306,7 +2306,7 @@ If a `before_add` callback throws an exception, the object does not get added to
 You're not limited to the functionality that Rails automatically builds into association proxy objects. You can also extend these objects through anonymous modules, adding new finders, creators, or other methods. For example:
 
 ```ruby
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders do
     def find_by_order_prefix(order_number)
       find_by(region_id: order_number[0..2])
@@ -2324,11 +2324,11 @@ module FindRecentExtension
   end
 end
 
-class Customer < ActiveRecord::Base
+class Customer < ApplicationRecord
   has_many :orders, -> { extending FindRecentExtension }
 end
 
-class Supplier < ActiveRecord::Base
+class Supplier < ApplicationRecord
   has_many :deliveries, -> { extending FindRecentExtension }
 end
 ```
diff --git a/guides/source/autoloading_and_reloading_constants.md b/guides/source/autoloading_and_reloading_constants.md
index a39b975c3e..de0fa2fdc0 100644
--- a/guides/source/autoloading_and_reloading_constants.md
+++ b/guides/source/autoloading_and_reloading_constants.md
@@ -181,14 +181,14 @@ constant.
 That is,
 
 ```ruby
-class Project < ActiveRecord::Base
+class Project < ApplicationRecord
 end
 ```
 
 performs a constant assignment equivalent to
 
 ```ruby
-Project = Class.new(ActiveRecord::Base)
+Project = Class.new(ApplicationRecord)
 ```
 
 including setting the name of the class as a side-effect:
@@ -912,7 +912,7 @@ these classes:
 
 ```ruby
 # app/models/polygon.rb
-class Polygon < ActiveRecord::Base
+class Polygon < ApplicationRecord
 end
 
 # app/models/triangle.rb
@@ -987,7 +987,7 @@ root class:
 
 ```ruby
 # app/models/polygon.rb
-class Polygon < ActiveRecord::Base
+class Polygon < ApplicationRecord
 end
 require_dependency ‘square’
 ```
diff --git a/guides/source/caching_with_rails.md b/guides/source/caching_with_rails.md
index 9a56233e4a..3a1a1ccfe6 100644
--- a/guides/source/caching_with_rails.md
+++ b/guides/source/caching_with_rails.md
@@ -175,11 +175,11 @@ your app will serve stale data. To fix this, we tie the models together with
 the `touch` method:
 
 ```ruby
-class Product < ActiveRecord::Base
+class Product < ApplicationRecord
   has_many :games
 end
 
-class Game < ActiveRecord::Base
+class Game < ApplicationRecord
   belongs_to :product, touch: true
 end
 ```
@@ -284,7 +284,7 @@ The most efficient way to implement low-level caching is using the `Rails.cache.
 Consider the following example. An application has a `Product` model with an instance method that looks up the product’s price on a competing website. The data returned by this method would be perfect for low-level caching:
 
 ```ruby
-class Product < ActiveRecord::Base
+class Product < ApplicationRecord
   def competing_price
     Rails.cache.fetch("#{cache_key}/competing_price", expires_in: 12.hours) do
       Competitor::API.find_price(id)
diff --git a/guides/source/debugging_rails_applications.md b/guides/source/debugging_rails_applications.md
index 5424313b33..0046ff7b4e 100644
--- a/guides/source/debugging_rails_applications.md
+++ b/guides/source/debugging_rails_applications.md
@@ -608,7 +608,7 @@ Started GET "/" for 127.0.0.1 at 2014-04-11 13:39:23 +0200
 Processing by ArticlesController#index as HTML
 
 [1, 8] in /home/davidr/Proyectos/test_app/app/models/article.rb
-   1: class Article < ActiveRecord::Base
+   1: class Article < ApplicationRecord
    2:
    3:   def self.find_recent(limit = 10)
    4:     byebug
diff --git a/guides/source/form_helpers.md b/guides/source/form_helpers.md
index 93bb51557a..2a289dd33a 100644
--- a/guides/source/form_helpers.md
+++ b/guides/source/form_helpers.md
@@ -880,12 +880,12 @@ Many apps grow beyond simple forms editing a single object. For example, when cr
 Active Record provides model level support via the `accepts_nested_attributes_for` method:
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   has_many :addresses
   accepts_nested_attributes_for :addresses
 end
 
-class Address < ActiveRecord::Base
+class Address < ApplicationRecord
   belongs_to :person
 end
 ```
@@ -973,7 +973,7 @@ private
 You can allow users to delete associated objects by passing `allow_destroy: true` to `accepts_nested_attributes_for`
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   has_many :addresses
   accepts_nested_attributes_for :addresses, allow_destroy: true
 end
@@ -1014,7 +1014,7 @@ end
 It is often useful to ignore sets of fields that the user has not filled in. You can control this by passing a `:reject_if` proc to `accepts_nested_attributes_for`. This proc will be called with each hash of attributes submitted by the form. If the proc returns `false` then Active Record will not build an associated object for that hash. The example below only tries to build an address if the `kind` attribute is set.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   has_many :addresses
   accepts_nested_attributes_for :addresses, reject_if: lambda {|attributes| attributes['kind'].blank?}
 end
diff --git a/guides/source/getting_started.md b/guides/source/getting_started.md
index 1416d00de5..d8b590dba1 100644
--- a/guides/source/getting_started.md
+++ b/guides/source/getting_started.md
@@ -990,21 +990,22 @@ and restart the web server when a change is made.
 The model file, `app/models/article.rb` is about as simple as it can get:
 
 ```ruby
-class Article < ActiveRecord::Base
+class Article < ApplicationRecord
 end
 ```
 
 There isn't much to this file - but note that the `Article` class inherits from
-`ActiveRecord::Base`. Active Record supplies a great deal of functionality to
-your Rails models for free, including basic database CRUD (Create, Read, Update,
-Destroy) operations, data validation, as well as sophisticated search support
-and the ability to relate multiple models to one another.
+`ApplicationRecord`. `ApplicationRecord` inherits from `ActiveRecord::Base`
+which supplies a great deal of functionality to your Rails models for free,
+including basic database CRUD (Create, Read, Update, Destroy) operations, data
+validation, as well as sophisticated search support and the ability to relate
+multiple models to one another.
 
 Rails includes methods to help you validate the data that you send to models.
 Open the `app/models/article.rb` file and edit it:
 
 ```ruby
-class Article < ActiveRecord::Base
+class Article < ApplicationRecord
   validates :title, presence: true,
                     length: { minimum: 5 }
 end
@@ -1529,7 +1530,7 @@ This command will generate four files:
 First, take a look at `app/models/comment.rb`:
 
 ```ruby
-class Comment < ActiveRecord::Base
+class Comment < ApplicationRecord
   belongs_to :article
 end
 ```
@@ -1587,7 +1588,7 @@ association. You've already seen the line of code inside the `Comment` model
 (app/models/comment.rb) that makes each comment belong to an Article:
 
 ```ruby
-class Comment < ActiveRecord::Base
+class Comment < ApplicationRecord
   belongs_to :article
 end
 ```
@@ -1596,7 +1597,7 @@ You'll need to edit `app/models/article.rb` to add the other side of the
 association:
 
 ```ruby
-class Article < ActiveRecord::Base
+class Article < ApplicationRecord
   has_many :comments
   validates :title, presence: true,
                     length: { minimum: 5 }
@@ -1962,7 +1963,7 @@ you to use the `dependent` option of an association to achieve this. Modify the
 Article model, `app/models/article.rb`, as follows:
 
 ```ruby
-class Article < ActiveRecord::Base
+class Article < ApplicationRecord
   has_many :comments, dependent: :destroy
   validates :title, presence: true,
                     length: { minimum: 5 }
diff --git a/guides/source/i18n.md b/guides/source/i18n.md
index 8381636196..42589110b1 100644
--- a/guides/source/i18n.md
+++ b/guides/source/i18n.md
@@ -816,7 +816,7 @@ This gives you quite powerful means to flexibly adjust your messages to your app
 Consider a User model with a validation for the name attribute like this:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   validates :name, presence: true
 end
 ```
diff --git a/guides/source/nested_model_forms.md b/guides/source/nested_model_forms.md
index 121cf2b185..71efa4b0d0 100644
--- a/guides/source/nested_model_forms.md
+++ b/guides/source/nested_model_forms.md
@@ -32,7 +32,7 @@ For an ActiveRecord::Base model and association this writer method is commonly d
 #### has_one
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   has_one :address
   accepts_nested_attributes_for :address
 end
@@ -41,7 +41,7 @@ end
 #### belongs_to
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   belongs_to :firm
   accepts_nested_attributes_for :firm
 end
@@ -50,7 +50,7 @@ end
 #### has_many / has_and_belongs_to_many
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   has_many :projects
   accepts_nested_attributes_for :projects
 end
diff --git a/guides/source/routing.md b/guides/source/routing.md
index fc756d00b3..2b1254f7a0 100644
--- a/guides/source/routing.md
+++ b/guides/source/routing.md
@@ -252,11 +252,11 @@ TIP: _If you need to use a different controller namespace inside a `namespace` b
 It's common to have resources that are logically children of other resources. For example, suppose your application includes these models:
 
 ```ruby
-class Magazine < ActiveRecord::Base
+class Magazine < ApplicationRecord
   has_many :ads
 end
 
-class Ad < ActiveRecord::Base
+class Ad < ApplicationRecord
   belongs_to :magazine
 end
 ```
@@ -1099,7 +1099,7 @@ You can override `ActiveRecord::Base#to_param` of a related model to construct
 a URL:
 
 ```ruby
-class Video < ActiveRecord::Base
+class Video < ApplicationRecord
   def to_param
     identifier
   end
diff --git a/guides/source/security.md b/guides/source/security.md
index b301736c36..1d0e87d831 100644
--- a/guides/source/security.md
+++ b/guides/source/security.md
@@ -171,7 +171,7 @@ NOTE: _Sessions that never expire extend the time-frame for attacks such as cros
 One possibility is to set the expiry time-stamp of the cookie with the session id. However the client can edit cookies that are stored in the web browser so expiring sessions on the server is safer. Here is an example of how to _expire sessions in a database table_. Call `Session.sweep("20 minutes")` to expire sessions that were used longer than 20 minutes ago.
 
 ```ruby
-class Session < ActiveRecord::Base
+class Session < ApplicationRecord
   def self.sweep(time = 1.hour)
     if time.is_a?(String)
       time = time.split.inject { |count, unit| count.to_i.send(unit) }
diff --git a/guides/source/testing.md b/guides/source/testing.md
index 58524fd6c5..a4b62955c5 100644
--- a/guides/source/testing.md
+++ b/guides/source/testing.md
@@ -177,7 +177,7 @@ Saved the article without a title
 Now to get this test to pass we can add a model level validation for the _title_ field.
 
 ```ruby
-class Article < ActiveRecord::Base
+class Article < ApplicationRecord
   validates :title, presence: true
 end
 ```