Use ApplicationModel in the Rails guides.

The ApplicationModel should replace all instances where models subclass
from ActiveRecord::Base.

Author: wangjohn

guides/source/action_view_overview.md

@@ -1035,11 +1035,11 @@ Returns `select` and `option` tags for the collection of existing return values
 Example object structure for use with this method:
 
 ```ruby
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   belongs_to :author
 end
 
-class Author < ActiveRecord::Base
+class Author < ApplicationRecord
   has_many :posts
   def name_with_initial
     "#{first_name.first}. #{last_name}"
@@ -1071,11 +1071,11 @@ Returns `radio_button` tags for the collection of existing return values of `met
 Example object structure for use with this method:
 
 ```ruby
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   belongs_to :author
 end
 
-class Author < ActiveRecord::Base
+class Author < ApplicationRecord
   has_many :posts
   def name_with_initial
     "#{first_name.first}. #{last_name}"
@@ -1107,11 +1107,11 @@ Returns `check_box` tags for the collection of existing return values of `method
 Example object structure for use with this method:
 
 ```ruby
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   has_and_belongs_to_many :authors
 end
 
-class Author < ActiveRecord::Base
+class Author < ApplicationRecord
   has_and_belongs_to_many :posts
   def name_with_initial
     "#{first_name.first}. #{last_name}"
@@ -1152,12 +1152,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

guides/source/active_record_basics.md

@@ -130,10 +130,10 @@ Creating Active Record Models
 -----------------------------
 
 It is very easy to create Active Record models. All you have to do is to
-subclass the `ActiveRecord::Base` class and you're good to go:
+subclass the `ApplicationRecord` class and you're good to go:
 
 ```ruby
-class Product < ActiveRecord::Base
+class Product < ApplicationRecord
 end
 ```
 
@@ -170,7 +170,7 @@ You can use the `ActiveRecord::Base.table_name=` method to specify the table
 name that should be used:
 
 ```ruby
-class Product < ActiveRecord::Base
+class Product < ApplicationRecord
   self.table_name = "PRODUCT"
 end
 ```
@@ -191,7 +191,7 @@ It's also possible to override the column that should be used as the table's
 primary key using the `ActiveRecord::Base.primary_key=` method:
 
 ```ruby
-class Product < ActiveRecord::Base
+class Product < ApplicationRecord
   self.primary_key = "product_id"
 end
 ```
@@ -318,7 +318,7 @@ they raise the exception `ActiveRecord::RecordInvalid` if validation fails.
 A quick example to illustrate:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   validates :name, presence: true
 end
 

guides/source/active_record_callbacks.md

@@ -29,7 +29,7 @@ Callbacks are methods that get called at certain moments of an object's life cyc
 In order to use the available callbacks, you need to register them. You can implement the callbacks as ordinary methods and use a macro-style class method to register them as callbacks:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   validates :login, :email, presence: true
 
   before_validation :ensure_login_has_a_value
@@ -46,7 +46,7 @@ end
 The macro-style class methods can also receive a block. Consider using this style if the code inside your block is so short that it fits in a single line:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   validates :login, :email, presence: true
 
   before_create do
@@ -58,7 +58,7 @@ end
 Callbacks can also be registered to only fire on certain lifecycle events:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   before_validation :normalize_name, on: :create
 
   # :on takes an array as well
@@ -121,7 +121,7 @@ The `after_find` callback will be called whenever Active Record loads a record f
 The `after_initialize` and `after_find` callbacks have no `before_*` counterparts, but they can be registered just like the other Active Record callbacks.
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   after_initialize do |user|
     puts "You have initialized an object!"
   end
@@ -212,11 +212,11 @@ Relational Callbacks
 Callbacks work through model relationships, and can even be defined by them. Suppose an example where a user has many posts. A user's posts should be destroyed if the user is destroyed. Let's add an `after_destroy` callback to the `User` model by way of its relationship to the `Post` model:
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   has_many :posts, dependent: :destroy
 end
 
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   after_destroy :log_destroy_action
 
   def log_destroy_action
@@ -243,7 +243,7 @@ As with validations, we can also make the calling of a callback method condition
 You can associate the `:if` and `:unless` options with a symbol corresponding to the name of a predicate method that will get called right before the callback. When using the `:if` option, the callback won't be executed if the predicate method returns false; when using the `:unless` option, the callback won't be executed if the predicate method returns true. This is the most common option. Using this form of registration it is also possible to register several different predicates that should be called to check if the callback should be executed.
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   before_save :normalize_card_number, if: :paid_with_card?
 end
 ```
@@ -253,7 +253,7 @@ end
 You can also use a string that will be evaluated using `eval` and hence needs to contain valid Ruby code. You should use this option only when the string represents a really short condition:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   before_save :normalize_card_number, if: "paid_with_card?"
 end
 ```
@@ -263,7 +263,7 @@ end
 Finally, it is possible to associate `:if` and `:unless` with a `Proc` object. This option is best suited when writing short validation methods, usually one-liners:
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   before_save :normalize_card_number,
     if: Proc.new { |order| order.paid_with_card? }
 end
@@ -274,7 +274,7 @@ end
 When writing conditional callbacks, it is possible to mix both `:if` and `:unless` in the same callback declaration:
 
 ```ruby
-class Comment < ActiveRecord::Base
+class Comment < ApplicationRecord
   after_create :send_email_to_author, if: :author_wants_emails?,
     unless: Proc.new { |comment| comment.post.ignore_comments? }
 end
@@ -300,7 +300,7 @@ end
 When declared inside a class, as above, the callback methods will receive the model object as a parameter. We can now use the callback class in the model:
 
 ```ruby
-class PictureFile < ActiveRecord::Base
+class PictureFile < ApplicationRecord
   after_destroy PictureFileCallbacks.new
 end
 ```
@@ -320,7 +320,7 @@ end
 If the callback method is declared this way, it won't be necessary to instantiate a `PictureFileCallbacks` object.
 
 ```ruby
-class PictureFile < ActiveRecord::Base
+class PictureFile < ApplicationRecord
   after_destroy PictureFileCallbacks
 end
 ```
@@ -344,7 +344,7 @@ end
 By using the `after_commit` callback we can account for this case.
 
 ```ruby
-class PictureFile < ActiveRecord::Base
+class PictureFile < ApplicationRecord
   after_commit :delete_picture_file_from_disk, on: [:destroy]
 
   def delete_picture_file_from_disk

guides/source/active_record_querying.md

@@ -22,27 +22,27 @@ Code examples throughout this guide will refer to one or more of the following m
 TIP: All of the following models use `id` as the primary key, unless specified otherwise.
 
 ```ruby
-class Client < ActiveRecord::Base
+class Client < ApplicationRecord
   has_one :address
   has_many :orders
   has_and_belongs_to_many :roles
 end
 ```
 
 ```ruby
-class Address < ActiveRecord::Base
+class Address < ApplicationRecord
   belongs_to :client
 end
 ```
 
 ```ruby
-class Order < ActiveRecord::Base
+class Order < ApplicationRecord
   belongs_to :client, counter_cache: true
 end
 ```
 
 ```ruby
-class Role < ActiveRecord::Base
+class Role < ApplicationRecord
   has_and_belongs_to_many :clients
 end
 ```
@@ -747,7 +747,7 @@ SELECT "posts".* FROM "posts" WHERE (id > 10) ORDER BY id desc LIMIT 20
 The `reorder` method overrides the default scope order. For example:
 
 ```ruby
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   ..
   ..
   has_many :comments, -> { order('posted_at DESC') }
@@ -870,7 +870,7 @@ This behavior can be turned off by setting `ActiveRecord::Base.lock_optimistical
 To override the name of the `lock_version` column, `ActiveRecord::Base` provides a class attribute called `locking_column`:
 
 ```ruby
-class Client < ActiveRecord::Base
+class Client < ApplicationRecord
   self.locking_column = :lock_client_column
 end
 ```
@@ -946,26 +946,26 @@ Active Record lets you use the names of the [associations](association_basics.ht
 For example, consider the following `Category`, `Post`, `Comments` and `Guest` models:
 
 ```ruby
-class Category < ActiveRecord::Base
+class Category < ApplicationRecord
   has_many :posts
 end
 
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   belongs_to :category
   has_many :comments
   has_many :tags
 end
 
-class Comment < ActiveRecord::Base
+class Comment < ApplicationRecord
   belongs_to :post
   has_one :guest
 end
 
-class Guest < ActiveRecord::Base
+class Guest < ApplicationRecord
   belongs_to :comment
 end
 
-class Tag < ActiveRecord::Base
+class Tag < ApplicationRecord
   belongs_to :post
 end
 ```
@@ -1142,15 +1142,15 @@ Scoping allows you to specify commonly-used queries which can be referenced as m
 To define a simple scope, we use the `scope` method inside the class, passing the query that we'd like to run when this scope is called:
 
 ```ruby
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   scope :published, -> { where(published: true) }
 end
 ```
 
 This is exactly the same as defining a class method, and which you use is a matter of personal preference:
 
 ```ruby
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   def self.published
     where(published: true)
   end
@@ -1160,7 +1160,7 @@ end
 Scopes are also chainable within scopes:
 
 ```ruby
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   scope :published,               -> { where(published: true) }
   scope :published_and_commented, -> { published.where("comments_count > 0") }
 end
@@ -1184,7 +1184,7 @@ category.posts.published # => [published posts belonging to this category]
 Your scope can take arguments:
 
 ```ruby
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   scope :created_before, ->(time) { where("created_at < ?", time) }
 end
 ```
@@ -1198,7 +1198,7 @@ Post.created_before(Time.zone.now)
 However, this is just duplicating the functionality that would be provided to you by a class method.
 
 ```ruby
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   def self.created_before(time)
     where("created_at < ?", time)
   end
@@ -1216,7 +1216,7 @@ category.posts.created_before(time)
 Just like `where` clauses scopes are merged using `AND` conditions.
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   scope :active, -> { where state: 'active' }
   scope :inactive, -> { where state: 'inactive' }
 end
@@ -1245,7 +1245,7 @@ One important caveat is that `default_scope` will be overridden by
 `scope` and `where` conditions.
 
 ```ruby
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   default_scope { where state: 'pending' }
   scope :active, -> { where state: 'active' }
   scope :inactive, -> { where state: 'inactive' }
@@ -1271,7 +1271,7 @@ If we wish for a scope to be applied across all queries to the model we can use
 `default_scope` method within the model itself.
 
 ```ruby
-class Client < ActiveRecord::Base
+class Client < ApplicationRecord
   default_scope { where("removed_at IS NULL") }
 end
 ```
@@ -1287,7 +1287,7 @@ If you need to do more complex things with a default scope, you can alternativel
 define it as a class method:
 
 ```ruby
-class Client < ActiveRecord::Base
+class Client < ApplicationRecord
   def self.default_scope
     # Should return an ActiveRecord::Relation.
   end
@@ -1490,7 +1490,7 @@ a large or often-running query. However, any model method overrides will
 not be available. For example:
 
 ```ruby
-class Client < ActiveRecord::Base
+class Client < ApplicationRecord
   def name
     "I am #{super}"
   end
@@ -1525,7 +1525,7 @@ Person.ids
 ```
 
 ```ruby
-class Person < ActiveRecord::Base
+class Person < ApplicationRecord
   self.primary_key = "person_id"
 end