Que fait inverse_of? Quel SQL génère-t-il?

J'essaye de comprendre inverse_ofet je ne comprends pas.

À quoi ressemble le SQL généré, le cas échéant?

Est -ce que l' inverse_ofoption de le même comportement si elle est utilisée avec :has_many, :belongs_toet :has_many_and_belongs_to?

Désolé si c'est une question si fondamentale.

J'ai vu cet exemple:

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

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

D'après la documentation , il semble que l' :inverse_ofoption soit une méthode pour éviter les requêtes SQL, pas pour les générer. C'est un conseil à ActiveRecord d'utiliser des données déjà chargées au lieu de les récupérer à travers une relation.

Leur exemple:

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

Dans ce cas, l'appel dungeon.traps.first.dungeondoit retourner l' dungeonobjet d' origine au lieu d'en charger un nouveau comme ce serait le cas par défaut.

Je pense que :inverse_ofc'est plus utile lorsque vous travaillez avec des associations qui n'ont pas encore été maintenues. Par exemple:

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

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

Maintenant, dans la console:

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

Sans les :inverse_ofarguments, t.projectretournerait nil, car il déclenche une requête SQL et les données ne sont pas encore stockées. Avec les :inverse_ofarguments, les données sont extraites de la mémoire.

Après ce pr ( https://github.com/rails/rails/pull/9522 ) inverse_of n'est pas nécessaire dans la plupart des cas.

Active Record prend en charge l'identification automatique pour la plupart des associations avec des noms standard. Cependant, Active Record n'identifiera pas automatiquement les associations bidirectionnelles contenant une étendue ou l'une des options suivantes:

• :à travers
• :clé étrangère

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

Dans l'exemple ci-dessus, une référence au même objet est stockée dans la variable aet dans l'attribut writer.

Juste une mise à jour pour tout le monde - nous venons de l'utiliser inverse_ofavec l'une de nos applications avec une has_many :throughassociation

Il met essentiellement l’objet «origine» à la disposition de l’objet «enfant»

Donc, si vous utilisez l'exemple des 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

L'utilisation :inverse_ofvous permettra d'accéder à l'objet de données dont il est l'inverse, sans effectuer d'autres requêtes SQL

Lorsque nous avons 2 modèles avec une relation has_many et appartient_to, il est toujours préférable d'utiliser inverse_of qui informe ActiveRecod qu'ils appartiennent du même côté de l'association. Ainsi, si une requête d'un côté est déclenchée, elle sera mise en cache et servira à partir du cache si elle est déclenchée dans la direction opposée. Ce qui améliore les performances. À partir de Rails 4.1, inverse_of sera défini automatiquement, si nous utilisons une clé étrangère ou des changements de nom de classe, nous devons définir explicitement.

Meilleur article pour les détails et l'exemple.

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

Jetez un œil à cet article !!

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

Si vous avez une has_many_throughrelation entre deux modèles, Utilisateur et Rôle, et que vous souhaitez valider l'affectation du modèle de connexion par rapport à des entrées non existantes ou non valides avec validates_presence of :user_id, :role_id, c'est utile. Vous pouvez toujours générer un utilisateur @user avec son association @user.role(params[:role_id])afin que l'enregistrement de l'utilisateur n'entraîne pas un échec de validation du modèle d'affectation.

Veuillez jeter un oeil 2 deux ressources utiles

• 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

Et rappelez-vous certaines limites de inverse_of:

ne fonctionne pas avec: par les associations.

ne fonctionne pas avec: les associations polymorphes.

pour les associations appartient_to, de nombreuses associations inverses sont ignorées.