Strict_loading function to suppress the occurrence of N + 1 problem added from rails 6.1

Since rails 6.1rc has been released, we have summarized the new strict_loading features. See: https://weblog.rubyonrails.org/releases/

1. #strict_loading

By marking an object, the exception ActiveRecord :: StrictLoadingViolationError will be thrown when the object is loaded with an association delay.

$ dev = Developer.strict_loading.first
$ dev.audit_logs.to_a
=> ActiveRecord::StrictLoadingViolationError: Developer is marked as strict_loading and AuditLog cannot be lazily loaded.

See: https://github.com/rails/rails/pull/37400

2. has_many :projects, strict_loading: true How to set in the association option. Exception ActiveRecord :: StrictLoadingViolationError is thrown when lazy loading is performed on all specified associations.

class Developer < ApplicationRecord
  has_many :projects, strict_loading: true
end

dev = Developer.first
dev.projects.first
# => ActiveRecord::StrictLoadingViolationError: The projects association is marked as strict_loading and cannot be lazily loaded.

See: https://github.com/rails/rails/pull/38541

3. self.strict_loading_by_default = true How to specify in model units. All associations from the entire specified model will raise the exception ActiveRecord :: StrictLoadingViolationError when lazy loading.

class Developer < ApplicationRecord
  self.strict_loading_by_default = true

  has_many :projects
end

dev = Developer.first
dev.projects.first
# => ActiveRecord::StrictLoadingViolationError Exception: Developer is marked as strict_loading and Project cannot be lazily loaded.

See: https://github.com/rails/rails/pull/39491

Other

It is now possible to select log output as well as exception occurrence in the behavior when strict_loding is detected.

config.active_record.action_on_strict_loading_violation enables raising or logging an exception if strict_loading is set on an association. The default value is :raise in all environments. It can be changed to :log to send violations to the logger instead of raising.

config.active_record.action_on_strict_loading_violation = :log

See https://github.com/rails/rails/pull/40511 https://edgeguides.rubyonrails.org/configuring.html#configuring-active-record

This makes it possible to raise an exception in the development and test environments and keep the log output in the production environment.

Discussion at WTF

The community is also actively discussing ways to prevent N + 1 from occurring. https://discuss.rubyonrails.org/t/n-1-queries-should-be-the-exception-not-the-easy-trap-to-fall-in/74537/14