From 3a0975c67ba7c2f6404ed104367e7d8519900b64 Mon Sep 17 00:00:00 2001
From: Andy Waite <andyw8@users.noreply.github.com>
Date: Sat, 5 Feb 2022 21:19:17 -0500
Subject: [PATCH] Replace references to `ActiveRecord::Base` with
 `ApplicationRecord`

---
 README.adoc | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/README.adoc b/README.adoc
index 0bd83ec..4a174ae 100644
--- a/README.adoc
+++ b/README.adoc
@@ -179,11 +179,11 @@ Use nested routes to express better the relationship between Active Record model
 
 [source,ruby]
 ----
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   has_many :comments
 end
 
-class Comment < ActiveRecord::Base
+class Comment < ApplicationRecord
   belongs_to :post
 end
 
@@ -402,7 +402,7 @@ Avoid altering Active Record defaults (table names, primary key, etc) unless you
 [source,ruby]
 ----
 # bad - don't do this if you can modify the schema
-class Transaction < ActiveRecord::Base
+class Transaction < ApplicationRecord
   self.table_name = 'order'
   ...
 end
@@ -416,7 +416,7 @@ lead to broken code.
 
 [source,ruby]
 ----
-class Transaction < ActiveRecord::Base
+class Transaction < ApplicationRecord
   # bad - implicit values - ordering matters
   enum type: %i[credit debit]
 
@@ -434,7 +434,7 @@ Group macro-style methods (`has_many`, `validates`, etc) in the beginning of the
 
 [source,ruby]
 ----
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   # keep the default scope first (if any)
   default_scope { where(active: true) }
 
@@ -479,26 +479,26 @@ Using `has_many :through` allows additional attributes and validations on the jo
 [source,ruby]
 ----
 # not so good - using has_and_belongs_to_many
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   has_and_belongs_to_many :groups
 end
 
-class Group < ActiveRecord::Base
+class Group < ApplicationRecord
   has_and_belongs_to_many :users
 end
 
 # preferred way - using has_many :through
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   has_many :memberships
   has_many :groups, through: :memberships
 end
 
-class Membership < ActiveRecord::Base
+class Membership < ApplicationRecord
   belongs_to :user
   belongs_to :group
 end
 
-class Group < ActiveRecord::Base
+class Group < ApplicationRecord
   has_many :memberships
   has_many :users, through: :memberships
 end
@@ -630,7 +630,7 @@ Use named scopes freely.
 
 [source,ruby]
 ----
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   scope :active, -> { where(active: true) }
   scope :inactive, -> { where(active: false) }
 
@@ -645,7 +645,7 @@ Arguably you can define even simpler scopes like this.
 
 [source,ruby]
 ----
-class User < ActiveRecord::Base
+class User < ApplicationRecord
   def self.with_orders
     joins(:orders).select('distinct(users.id)')
   end
@@ -792,12 +792,12 @@ Define the `dependent` option to the `has_many` and `has_one` associations.
 [source,ruby]
 ----
 # bad
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   has_many :comments
 end
 
 # good
-class Post < ActiveRecord::Base
+class Post < ApplicationRecord
   has_many :comments, dependent: :destroy
 end
 ----
@@ -1046,7 +1046,7 @@ Enforce default values in the migrations themselves instead of in the applicatio
 [source,ruby]
 ----
 # bad - application enforced default value
-class Product < ActiveRecord::Base
+class Product < ApplicationRecord
   def amount
     self[:amount] || 0
   end
@@ -1162,7 +1162,7 @@ end
 # same table you had during the creation of the migration.
 # In future if you override the `Product` class and change the `table_name`,
 # it won't break the migration or cause serious data corruption.
-class MigrationProduct < ActiveRecord::Base
+class MigrationProduct < ApplicationRecord
   self.table_name = :products
 end