It's a common practice to define AR models inside of migrations in order to retain forward compatibility of the migration by avoiding loading any code from app/ (gems like strong_migrations and my own good_migrations are designed to enforce this).
Example from the codebase I'm working on:
class AddDefaultTrackingValuesToMovements < ActiveRecord::Migration[7.2]
module Build
class Movement < ActiveRecord::Base
self.table_name = "build_movements"
end
end
def change
Build::Movement.update_all(default_tracking_type: nil)
change_table :build_movements do |t|
t.jsonb :default_tracking_values, null: true
end
end
end
This results in:
db/migrate/20240809113624_add_default_tracking_values_to_movements.rb:3:22: Rails/ApplicationRecord: Models should subclass `ApplicationRecord`.
Of course, if we fixed this by extending from ApplicationRecord, that'd load the model from app/models/application_record.rb, which could change in a way such that the migration couldn't be safely run again in the future. I think the cop should ignore anything under db/migrate/** as a result
It's a common practice to define AR models inside of migrations in order to retain forward compatibility of the migration by avoiding loading any code from
app/
(gems like strong_migrations and my own good_migrations are designed to enforce this).Example from the codebase I'm working on:
This results in:
Of course, if we fixed this by extending from
ApplicationRecord
, that'd load the model fromapp/models/application_record.rb
, which could change in a way such that the migration couldn't be safely run again in the future. I think the cop should ignore anything underdb/migrate/**
as a result