带有ActiveRecord的rails 3中inverse_of的限制是什么

Question

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

inverse_of支持有一些限制:

• 它们不适用于:通过协会.
• 它们不兼容:多态关联.
• 它们不适用于:作为协会.
• 对于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不能通过关联工作,这个页面说

如果在连接模型上使用belongs_to,最好在belongs_to上设置:inverse_of>选项,这意味着以下示例在> tags是has_many:through association)的情况下正常工作:

并给出了这个例子

@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

对我来说,这一切似乎都是不一致和高度混乱的.但总的来说,我认为对每一种关系都说反转都没有害处.那是问题吗？我见过很多人在SO上问这个问题,并没有看到任何人的肯定是或否.

Answer 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 有关反向关系的信息，并且它将优化对象加载。