Co robi inverse_of? Jaki SQL generuje?

Próbuję się rozejrzeć inverse_ofi nie rozumiem.

Jak wygląda wygenerowany plik sql, jeśli w ogóle?

Czy inverse_ofopcja wykazują takie samo zachowanie, jeśli stosować :has_many, :belongs_toi :has_many_and_belongs_to?

Przepraszam, jeśli to takie podstawowe pytanie.

Widziałem ten przykład:

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

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

Z dokumentacji wynika , że :inverse_ofopcja jest sposobem na uniknięcie zapytań SQL, a nie ich generowanie. Jest to wskazówka dla ActiveRecord, aby używać już załadowanych danych zamiast pobierać je ponownie za pośrednictwem relacji.

Ich przykład:

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

W takim przypadku wywołanie dungeon.traps.first.dungeonpowinno zwrócić oryginalny dungeonobiekt zamiast ładować nowy, jak byłoby to w przypadku domyślnym.

Myślę, że :inverse_ofjest to najbardziej przydatne, gdy pracujesz ze skojarzeniami, które nie zostały jeszcze utrwalone. Na przykład:

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

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

Teraz w konsoli:

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, ...>

Bez :inverse_ofargumentów t.projectzwróci nil, ponieważ wyzwala zapytanie sql, a dane nie są jeszcze zapisane. Wraz z :inverse_ofargumentami dane są pobierane z pamięci.

Po tym pr ( https://github.com/rails/rails/pull/9522 ) inverse_of nie jest wymagane w większości przypadków.

Moduł Active Record obsługuje automatyczną identyfikację większości skojarzeń ze standardowymi nazwami. Jednak moduł Active Record nie zidentyfikuje automatycznie powiązań dwukierunkowych, które zawierają zakres lub którąkolwiek z następujących opcji:

• :przez
• : klucz_obcy

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

W powyższym przykładzie odwołanie do tego samego obiektu jest przechowywane w zmiennej aoraz w atrybucie writer.

Tylko aktualizacja dla wszystkich - właśnie używaliśmy inverse_ofjednej z naszych aplikacji z has_many :throughpowiązaniem

Zasadniczo udostępnia obiekt „pochodzenie” obiektowi „potomnemu”

Więc jeśli używasz przykładu Railsów:

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

Użycie :inverse_ofumożliwia dostęp do obiektu danych, którego jest odwrotnością, bez wykonywania dalszych zapytań SQL

Kiedy mamy 2 modele z relacjami has_many i contrib_to, zawsze lepiej jest użyć inverse_of, które informują ActiveRecod, że należą do tej samej strony asocjacji. Więc jeśli zostanie wyzwolone zapytanie z jednej strony, będzie buforować i wyświetlać z pamięci podręcznej, jeśli zostanie wyzwolone z przeciwnego kierunku. Co poprawia wydajność. Od Rails 4.1, inverse_of zostanie ustawione automatycznie, jeśli użyjemy obcego_klucza lub zmian w nazwie klasy musimy ustawić jawnie.

Najlepszy artykuł ze szczegółami i przykładami.

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

Spójrz na ten artykuł !!

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

Jeśli masz has_many_throughrelację między dwoma modelami, użytkownikiem i rolą, i chcesz zweryfikować przypisanie modelu łączącego pod kątem nieistniejących lub nieprawidłowych wpisów za pomocą validates_presence of :user_id, :role_id, jest to przydatne. Nadal można wygenerować użytkownika @user z jego skojarzeniem @user.role(params[:role_id]), aby zapisanie użytkownika nie spowodowało niepowodzenia walidacji modelu przypisania.

Proszę spojrzeć na 2 dwa przydatne zasoby

• 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

I pamiętaj o ograniczeniach inverse_of:

nie działa z: poprzez skojarzenia.

nie działa z: skojarzeniami polimorficznymi.

dla przypisań należą_to ma_wiele asocjacji odwrotnych jest ignorowanych.