Что делает inverse_of? Какой SQL он генерирует?

Я пытаюсь осмыслить inverse_of но не понимаю.

Как выглядит сгенерированный sql, если есть?

Имеет ли inverse_ofвыставлять опции такое же поведение , если используется :has_many, :belongs_toи:has_many_and_belongs_to ?

Извините, если это такой простой вопрос.

Я видел такой пример:

class Player < ActiveRecord::Base
  has_many :cards, :inverse_of => :player
end

class Card < ActiveRecord::Base
  belongs_to :player, :inverse_of => :cards
end

Из документации кажется, что эта :inverse_ofопция - это способ избежать запросов SQL, а не их генерировать. Это подсказка ActiveRecord использовать уже загруженные данные вместо их повторной выборки через связь.

Их пример:

class Dungeon < ActiveRecord::Base
  has_many :traps, :inverse_of => :dungeon
  has_one :evil_wizard, :inverse_of => :dungeon
end

class Trap < ActiveRecord::Base
  belongs_to :dungeon, :inverse_of => :traps
end

class EvilWizard < ActiveRecord::Base
  belongs_to :dungeon, :inverse_of => :evil_wizard
end

В этом случае вызов dungeon.traps.first.dungeonдолжен возвращать исходный dungeonобъект вместо загрузки нового, как это было бы по умолчанию.

Я думаю, что :inverse_ofэто наиболее полезно, когда вы работаете с ассоциациями, которые еще не сохранились. Например:

class Project < ActiveRecord::Base
  has_many :tasks, :inverse_of=>:project
end

class Task < ActiveRecord::Base
  belongs_to :project, :inverse_of=>:tasks
end

Теперь в консоли:

irb> p = Project.new
=> #<Project id: nil, name: nil, ...>
irb> t = p.tasks.build
=> #<Task id: nil, project_id: nil, ...>
irb> t.project
=> #<Project id: nil, name: nil, ...>

Без :inverse_ofаргументов t.projectфункция вернется nil, поскольку запускает запрос sql, а данные еще не сохранены. С :inverse_ofаргументами данные извлекаются из памяти.

После этого pr ( https://github.com/rails/rails/pull/9522 ) inverse_of в большинстве случаев не требуется.

Active Record поддерживает автоматическую идентификацию для большинства ассоциаций со стандартными именами. Однако Active Record не будет автоматически определять двунаправленные ассоциации, которые содержат область действия или любой из следующих параметров:

• :через
• :внешний ключ

class Author < ApplicationRecord
  has_many :books, inverse_of: 'writer'
end

class Book < ApplicationRecord
  belongs_to :writer, class_name: 'Author', foreign_key: 'author_id'
end

a = Author.first
b = a.books.first
a.first_name == b.writer.first_name # => true
a.first_name = 'David'
a.first_name == b.writer.first_name # => true

В приведенном выше примере ссылка на один и тот же объект сохраняется в переменной aи в атрибуте writer.

Просто обновление для всех - мы только что использовали inverse_ofодно из наших приложений с has_many :throughассоциацией

По сути, он делает "исходный" объект доступным для "дочернего" объекта.

Итак, если вы используете пример Rails:

class Dungeon < ActiveRecord::Base
  has_many :traps, :inverse_of => :dungeon
  has_one :evil_wizard, :inverse_of => :dungeon
end

class Trap < ActiveRecord::Base
  belongs_to :dungeon, :inverse_of => :traps
  validates :id,
      :presence => { :message => "Dungeon ID Required", :unless => :draft? }

  private
  def draft?
      self.dungeon.draft
  end 
end

class EvilWizard < ActiveRecord::Base
  belongs_to :dungeon, :inverse_of => :evil_wizard
end

Использование :inverse_ofпозволит вам получить доступ к объекту данных, противоположному ему, без выполнения каких-либо дальнейших SQL-запросов.

Когда у нас есть 2 модели с отношениями has_many и own_to, всегда лучше использовать inverse_of, который информирует ActiveRecod о том, что они принадлежат одной стороне ассоциации. Таким образом, если запрос с одной стороны запускается, он будет кэшироваться и обслуживаться из кеша, если он запускается с противоположной стороны. Что улучшает производительность. Начиная с Rails 4.1, inverse_of будет установлен автоматически, если мы используем foreign_key или изменения в имени класса, которые нам нужно установить явно.

Лучшая статья для подробностей и примеров.

http://viget.com/extend/exploring-the-inverse-of-option-on-rails-model-associations

Взгляните на эту статью !!

http://gsusmonzon.blogspot.com.br/2011/09/rails-power-of-inverseof.html

Если у вас есть has_many_throughсвязь между двумя моделями, User и Role, и вы хотите проверить назначение подключаемой модели по несуществующим или недопустимым записям с помощью validates_presence of :user_id, :role_id, это полезно. Вы по-прежнему можете сгенерировать User @user с его ассоциацией, @user.role(params[:role_id])чтобы сохранение пользователя не привело к неудачной проверке модели присвоения.

Пожалуйста, посмотрите 2 два полезных ресурса

• https://www.viget.com/articles/exploring-the-inverse-of-option-on-rails-model-associations
• http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#module-ActiveRecord::Associations::ClassMethods-label-Bi-directional+associations

И помните о некоторых ограничениях inverse_of:

не работает: через ассоциации.

не работает с: полиморфными ассоциациями.

для ассоциаций принадлежит_то has_many обратные ассоциации игнорируются.