7

我一直在阅读有关 inverse_of 的内容，而我在网上看到的所有内容似乎都不一致并且让我感到困惑。如果你看这里，你可以看到

inverse_of 支持有一些限制：

  • 它们不适用于 :through 关联。
  • 它们不适用于 :polymorphic 关联。
  • 它们不适用于 :as 关联。
  • 对于belongs_to 关联，忽略has_many 反向关联。

但就在此之上，他们举了这个例子

class Customer < ActiveRecord::Base
   has_many :orders, :inverse_of => :customer
end

class Order < ActiveRecord::Base
   belongs_to :customer, :inverse_of => :orders
end

我认为他们说第一个 inverse_of 什么都不做，但如果是这样，他们为什么要这样做？

另外，即使上面的东西说 inverse_of 不能通过关联工作，这个页面说

如果您在连接模型上使用belongs_to，最好在belongs_to 上设置:inverse_of > 选项，这意味着以下示例在>tags 是has_many :through 关联的情况下可以正常工作）：

并给出这个例子

@post = Post.first
@tag = @post.tags.build :name => "ruby"
@tag.save

最后一行应该保存直通记录（Taggable）。这仅在设置 >:inverse_of 时才有效：

class Taggable < ActiveRecord::Base
  belongs_to :post
belongs_to :tag, :inverse_of => :taggings
end

对我来说，所有这些似乎都不一致且非常混乱。但总的来说，我认为对每个关系都说 inverse_of 并没有什么坏处。那是问题吗？我看到很多人在 SO 上问这个问题，但没有看到任何人给出明确的“是”或“否”。

4

1 回答 1

1

始终指定它并没有什么害处，它将允许 rails 优化对象的加载，因此您可以在两个方向上上下活动记录模型关系链，而不会出现奇怪的错误，即更改一个对象上的值不会改变它的引用.

将它设置在不起作用的地方的唯一问题是您之前所说的某些类型，如果它们静默失败，如果您在更改某些内容后在方法链中走错路，您将得到前面提到的错误

这是来自 rails API

d = Dungeon.first
t = d.traps.first
d.level == t.dungeon.level # => true
d.level = 10
d.level == t.dungeon.level # => false

上例中的 Dungeon 实例 d 和 t.dungeon 引用数据库中的相同对象数据，但实际上是该数据的不同内存副本。在关联上指定 :inverse_of 选项可以告诉 Active Record 反向关系，它会优化对象加载。

于 2013-08-13T08:21:03.483 回答