Introduce ApplicationRecord, an Active Record layer supertype

It's pretty common for folks to monkey patch `ActiveRecord::Base` to
work around an issue or introduce extra functionality. Instead of
shoving even more stuff in `ActiveRecord::Base`, `ApplicationRecord` can
hold all those custom work the apps may need.

Now, we don't wanna encourage all of the application models to inherit
from `ActiveRecord::Base`, but we can encourage all the models that do,
to inherit from `ApplicationRecord`.

Newly generated applications have `app/models/application_record.rb`
present by default. The model generators are smart enough to recognize
that newly generated models have to inherit from `ApplicationRecord`,
but only if it's present.

1 files changed, 54 insertions, 54 deletions

diff --git a/guides/source/active_record_validations.md b/guides/source/active_record_validations.md
index ec31385077..dd7adf09a2 100644
--- a/guides/source/active_record_validations.md
+++ b/guides/source/active_record_validations.md
@@ -20,7 +20,7 @@ Validations Overview
 Here's an example of a very simple validation:
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, presence: true
 end
 
@@ -80,7 +80,7 @@ method to determine whether an object is already in the database or not.
 Consider the following simple Active Record class:
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
 end
 ```
 
@@ -157,7 +157,7 @@ and returns true if no errors were found in the object, and false otherwise.
 As you saw above:
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, presence: true
 end
 
@@ -175,7 +175,7 @@ even if it's technically invalid, because validations are automatically run
 only when the object is saved, such as with the `create` or `save` methods.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, presence: true
 end
 
@@ -221,7 +221,7 @@ it doesn't verify the validity of the object as a whole. It only checks to see
 whether there are errors found on an individual attribute of the object.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, presence: true
 end
 
@@ -239,7 +239,7 @@ To check which validations failed on an invalid attribute, you can use
 key to get the symbol of the validator:
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, presence: true
 end
 
@@ -285,7 +285,7 @@ the field does exist in your database, the `accept` option must be set to
 `true` or else the validation will not run.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :terms_of_service, acceptance: true
 end
 ```
@@ -297,7 +297,7 @@ It can receive an `:accept` option, which determines the value that will be
 considered acceptance. It defaults to "1" and can be easily changed.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :terms_of_service, acceptance: { accept: 'yes' }
 end
 ```
@@ -309,7 +309,7 @@ and they also need to be validated. When you try to save your object, `valid?`
 will be called upon each one of the associated objects.
 
 ```ruby
-class Library < ActiveRecord::Base
+class Library < ApplicationRecord
   has_many :books
   validates_associated :books
 end
@@ -332,7 +332,7 @@ or a password. This validation creates a virtual attribute whose name is the
 name of the field that has to be confirmed with "_confirmation" appended.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :email, confirmation: true
 end
 ```
@@ -349,7 +349,7 @@ confirmation, make sure to add a presence check for the confirmation attribute
 (we'll take a look at `presence` later on in this guide):
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :email, confirmation: true
   validates :email_confirmation, presence: true
 end
@@ -360,7 +360,7 @@ confirmation constraint will be case sensitive or not. This option defaults to
 true.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :email, confirmation: { case_sensitive: false }
 end
 ```
@@ -373,7 +373,7 @@ This helper validates that the attributes' values are not included in a given
 set. In fact, this set can be any enumerable object.
 
 ```ruby
-class Account < ActiveRecord::Base
+class Account < ApplicationRecord
   validates :subdomain, exclusion: { in: %w(www us ca jp),
     message: "%{value} is reserved." }
 end
@@ -393,7 +393,7 @@ This helper validates the attributes' values by testing whether they match a
 given regular expression, which is specified using the `:with` option.
 
 ```ruby
-class Product < ActiveRecord::Base
+class Product < ApplicationRecord
   validates :legacy_code, format: { with: /\A[a-zA-Z]+\z/,
     message: "only allows letters" }
 end
@@ -409,7 +409,7 @@ This helper validates that the attributes' values are included in a given set.
 In fact, this set can be any enumerable object.
 
 ```ruby
-class Coffee < ActiveRecord::Base
+class Coffee < ApplicationRecord
   validates :size, inclusion: { in: %w(small medium large),
     message: "%{value} is not a valid size" }
 end
@@ -428,7 +428,7 @@ This helper validates the length of the attributes' values. It provides a
 variety of options, so you can specify length constraints in different ways:
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, length: { minimum: 2 }
   validates :bio, length: { maximum: 500 }
   validates :password, length: { in: 6..20 }
@@ -451,7 +451,7 @@ number corresponding to the length constraint being used. You can still use the
 `:message` option to specify an error message.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :bio, length: { maximum: 1000,
     too_long: "%{count} characters is the maximum allowed" }
 end
@@ -483,7 +483,7 @@ WARNING. Note that the regular expression above allows a trailing newline
 character.
 
 ```ruby
-class Player < ActiveRecord::Base
+class Player < ApplicationRecord
   validates :points, numericality: true
   validates :games_played, numericality: { only_integer: true }
 end
@@ -521,7 +521,7 @@ This helper validates that the specified attributes are not empty. It uses the
 is, a string that is either empty or consists of whitespace.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, :login, :email, presence: true
 end
 ```
@@ -531,7 +531,7 @@ whether the associated object itself is present, and not the foreign key used
 to map the association.
 
 ```ruby
-class LineItem < ActiveRecord::Base
+class LineItem < ApplicationRecord
   belongs_to :order
   validates :order, presence: true
 end
@@ -541,7 +541,7 @@ In order to validate associated records whose presence is required, you must
 specify the `:inverse_of` option for the association:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   has_many :line_items, inverse_of: :order
 end
 ```
@@ -568,7 +568,7 @@ This helper validates that the specified attributes are absent. It uses the
 is, a string that is either empty or consists of whitespace.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, :login, :email, absence: true
 end
 ```
@@ -578,7 +578,7 @@ whether the associated object itself is absent, and not the foreign key used
 to map the association.
 
 ```ruby
-class LineItem < ActiveRecord::Base
+class LineItem < ApplicationRecord
   belongs_to :order
   validates :order, absence: true
 end
@@ -588,7 +588,7 @@ In order to validate associated records whose absence is required, you must
 specify the `:inverse_of` option for the association:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   has_many :line_items, inverse_of: :order
 end
 ```
@@ -611,7 +611,7 @@ with the same value for a column that you intend to be unique. To avoid that,
 you must create a unique index on that column in your database.
 
 ```ruby
-class Account < ActiveRecord::Base
+class Account < ApplicationRecord
   validates :email, uniqueness: true
 end
 ```
@@ -623,7 +623,7 @@ There is a `:scope` option that you can use to specify one or more attributes th
 are used to limit the uniqueness check:
 
 ```ruby
-class Holiday < ActiveRecord::Base
+class Holiday < ApplicationRecord
   validates :name, uniqueness: { scope: :year,
     message: "should happen once per year" }
 end
@@ -635,7 +635,7 @@ uniqueness constraint will be case sensitive or not. This option defaults to
 true.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, uniqueness: { case_sensitive: false }
 end
 ```
@@ -658,7 +658,7 @@ class GoodnessValidator < ActiveModel::Validator
   end
 end
 
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates_with GoodnessValidator
 end
 ```
@@ -686,7 +686,7 @@ class GoodnessValidator < ActiveModel::Validator
   end
 end
 
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates_with GoodnessValidator, fields: [:first_name, :last_name]
 end
 ```
@@ -699,7 +699,7 @@ If your validator is complex enough that you want instance variables, you can
 easily use a plain old Ruby object instead:
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validate do |person|
     GoodnessValidator.new(person).validate
   end
@@ -728,7 +728,7 @@ passed to `validates_each` will be tested against it. In the following example,
 we don't want names and surnames to begin with lower case.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates_each :name, :surname do |record, attr, value|
     record.errors.add(attr, 'must start with upper case') if value =~ /\A[[:lower:]]/
   end
@@ -751,7 +751,7 @@ The `:allow_nil` option skips the validation when the value being validated is
 `nil`.
 
 ```ruby
-class Coffee < ActiveRecord::Base
+class Coffee < ApplicationRecord
   validates :size, inclusion: { in: %w(small medium large),
     message: "%{value} is not a valid size" }, allow_nil: true
 end
@@ -764,7 +764,7 @@ will let validation pass if the attribute's value is `blank?`, like `nil` or an
 empty string for example.
 
 ```ruby
-class Topic < ActiveRecord::Base
+class Topic < ApplicationRecord
   validates :title, length: { is: 5 }, allow_blank: true
 end
 
@@ -787,7 +787,7 @@ A `Proc` `:message` value is given two arguments: a message key for i18n, and
 a hash with `:model`, `:attribute`, and `:value` key-value pairs.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   # Hard-coded message
   validates :name, presence: { message: "must be given please" }
 
@@ -818,7 +818,7 @@ new record is created or `on: :update` to run the validation only when a record
 is updated.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   # it will be possible to update email with a duplicated value
   validates :email, uniqueness: true, on: :create
 
@@ -837,7 +837,7 @@ You can also specify validations to be strict and raise
 `ActiveModel::StrictValidationFailed` when the object is invalid.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, presence: { strict: true }
 end
 
@@ -847,7 +847,7 @@ Person.new.valid?  # => ActiveModel::StrictValidationFailed: Name can't be blank
 There is also the ability to pass a custom exception to the `:strict` option.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :token, presence: true, uniqueness: true, strict: TokenGenerationException
 end
 
@@ -871,7 +871,7 @@ to the name of a method that will get called right before validation happens.
 This is the most commonly used option.
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   validates :card_number, presence: true, if: :paid_with_card?
 
   def paid_with_card?
@@ -887,7 +887,7 @@ contain valid Ruby code. You should use this option only when the string
 represents a really short condition.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :surname, presence: true, if: "name.nil?"
 end
 ```
@@ -900,7 +900,7 @@ inline condition instead of a separate method. This option is best suited for
 one-liners.
 
 ```ruby
-class Account < ActiveRecord::Base
+class Account < ApplicationRecord
   validates :password, confirmation: true,
     unless: Proc.new { |a| a.password.blank? }
 end
@@ -912,7 +912,7 @@ Sometimes it is useful to have multiple validations use one condition. It can
 be easily achieved using `with_options`.
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   with_options if: :is_admin? do |admin|
     admin.validates :password, length: { minimum: 10 }
     admin.validates :email, presence: true
@@ -930,7 +930,7 @@ should happen, an `Array` can be used. Moreover, you can apply both `:if` and
 `:unless` to the same validation.
 
 ```ruby
-class Computer < ActiveRecord::Base
+class Computer < ApplicationRecord
   validates :mouse, presence: true,
                     if: ["market.retail?", :desktop?],
                     unless: Proc.new { |c| c.trackpad.present? }
@@ -984,7 +984,7 @@ class EmailValidator < ActiveModel::EachValidator
   end
 end
 
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :email, presence: true, email: true
 end
 ```
@@ -1008,7 +1008,7 @@ so your custom validation methods should add errors to it when you
 wish validation to fail:
 
 ```ruby
-class Invoice < ActiveRecord::Base
+class Invoice < ApplicationRecord
   validate :expiration_date_cannot_be_in_the_past,
     :discount_cannot_be_greater_than_total_value
 
@@ -1032,7 +1032,7 @@ custom validations by giving an `:on` option to the `validate` method,
 with either: `:create` or `:update`.
 
 ```ruby
-class Invoice < ActiveRecord::Base
+class Invoice < ApplicationRecord
   validate :active_customer, on: :create
 
   def active_customer
@@ -1053,7 +1053,7 @@ The following is a list of the most commonly used methods. Please refer to the `
 Returns an instance of the class `ActiveModel::Errors` containing all errors. Each key is the attribute name and the value is an array of strings with all errors.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, presence: true, length: { minimum: 3 }
 end
 
@@ -1072,7 +1072,7 @@ person.errors.messages # => {}
 `errors[]` is used when you want to check the error messages for a specific attribute. It returns an array of strings with all error messages for the given attribute, each string with one error message. If there are no errors related to the attribute, it returns an empty array.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, presence: true, length: { minimum: 3 }
 end
 
@@ -1097,7 +1097,7 @@ The `add` method lets you add an error message related to a particular attribute
 The `errors.full_messages` method (or its equivalent, `errors.to_a`) returns the error messages in a user-friendly format, with the capitalized attribute name prepended to each message, as shown in the examples below.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   def a_method_used_for_validation_purposes
     errors.add(:name, "cannot contain the characters !@#%*()_-+=")
   end
@@ -1115,7 +1115,7 @@ person.errors.full_messages
 An equivalent to `errors#add` is to use `<<` to append a message to the `errors.messages` array for an attribute:
 
 ```ruby
-  class Person < ActiveRecord::Base
+  class Person < ApplicationRecord
     def a_method_used_for_validation_purposes
       errors.messages[:name] << "cannot contain the characters !@#%*()_-+="
     end
@@ -1136,7 +1136,7 @@ You can specify a validator type to the returned error details hash using the
 `errors.add` method.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   def a_method_used_for_validation_purposes
     errors.add(:name, :invalid_characters)
   end
@@ -1152,7 +1152,7 @@ To improve the error details to contain the unallowed characters set for instanc
 you can pass additional keys to `errors.add`.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   def a_method_used_for_validation_purposes
     errors.add(:name, :invalid_characters, not_allowed: "!@#%*()_-+=")
   end
@@ -1172,7 +1172,7 @@ validator type.
 You can add error messages that are related to the object's state as a whole, instead of being related to a specific attribute. You can use this method when you want to say that the object is invalid, no matter the values of its attributes. Since `errors[:base]` is an array, you can simply add a string to it and it will be used as an error message.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   def a_method_used_for_validation_purposes
     errors[:base] << "This person is invalid because ..."
   end
@@ -1184,7 +1184,7 @@ end
 The `clear` method is used when you intentionally want to clear all the messages in the `errors` collection. Of course, calling `errors.clear` upon an invalid object won't actually make it valid: the `errors` collection will now be empty, but the next time you call `valid?` or any method that tries to save this object to the database, the validations will run again. If any of the validations fail, the `errors` collection will be filled again.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, presence: true, length: { minimum: 3 }
 end
 
@@ -1207,7 +1207,7 @@ p.errors[:name]
 The `size` method returns the total number of error messages for the object.
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   validates :name, presence: true, length: { minimum: 3 }
 end