在某些情况下，default_scope 会中断（更新|删除|销毁）_全部

Question

我相信这是 Rails 3 中的一个错误。我希望这里有人能引导我走向正确的方向。下面发布的代码纯粹是为了说明这个问题。希望这不会混淆问题。

鉴于我有一个帖子模型和一个评论模型。帖子有_许多评论，评论属于_帖子。

在 Post 模型上设置 default_scope，定义 join() 和 where() 关系。在这种情况下，where() 依赖于 joins()。

通常帖子不会依赖于评论。再次强调，我只想举一个简单的例子。当 where() 依赖于 joins() 时，这可能是任何情况。

class Post < ActiveRecord::Base
  has_many :comments, :dependent => :destroy

  default_scope joins(:comments).where("comments.id < 999")
end

class Comment < ActiveRecord::Base
  belongs_to :post, :counter_cache => true
end

运行以下命令：

Post.update_all(:title => Time.now)

生成以下查询，并最终抛出 ActiveRecord::StatementInvalid:

UPDATE `posts` SET `title` = '2010-10-15 15:59:27'  WHERE (comments.id < 999)

同样，update_all、delete_all、destroy_all 的行为方式相同。当我的应用程序在尝试更新 counter_cache 时抱怨时，我发现了这种行为。最终深入到 update_all。

Answer 1

我也遇到了这个问题，但我们确实需要能够在 default_scope 中使用具有复杂条件的 update_all （例如，没有默认范围，急切加载是不可能的，并且在任何地方粘贴命名范围一点也不有趣）。我在这里打开了一个拉取请求并进行了修复：

https://github.com/rails/rails/ pull/8449

对于delete_all，如果存在连接条件，我会引发错误，以使您必须执行的操作更加明显（而不是仅仅扔掉连接条件并在所有内容上运行delete_all，您会收到错误） 。

不确定 Rails 人员将如何处理我的拉取请求，但认为这与本次讨论相关。 （另外，如果您需要修复此错误，您可以尝试我的分支并在拉取请求上发表评论。）

Answer 2

我也遇到了这个问题。

如果你有

class Topic < ActiveRecord::Base
  default_scope :conditions => "forums.preferences > 1", :include => [:forum]
end

并且你这样做了，

Topic.update_all(...)

它会失败

Mysql::Error: Unknown column 'forums.preferences' in 'where clause'

。解决方法是：

Topic.send(:with_exclusive_scope) { Topic.update_all(...) }

你可以使用此代码（并在environment.rb或其他地方需要它）

module ActiveRecordMixins
  class ActiveRecord::Base
    def self.update_all!(*args)
      self.send(:with_exclusive_scope) { self.update_all(*args) }
    end
    def self.delete_all!(*args)
      self.send(:with_exclusive_scope) { self.delete_all(*args) }
    end
  end
end

end

然后只是你update_all！或删除全部！当它有默认范围时。

Answer 3

您还可以在类级别执行此操作，而无需创建新方法，如下所示：

def self.update_all(*args)
  self.send(:with_exclusive_scope) { super(*args) }
end

def self.delete_all(*args)
  self.send(:with_exclusive_scope) { super(*args) }
end

Answer 4

我不认为我会称其为错误。对我来说，这种行为似乎很合乎逻辑，尽管不是很明显。但我制定了一个似乎运行良好的 SQL 解决方案。使用您的示例，它会是：

class Post < ActiveRecord::Base
  has_many :comments, :dependent => :destroy

  default_scope do
    with_scope :find => {:readonly => false} do 
      joins("INNER JOIN comments ON comments.post_id = posts.id AND comments.id < 999")
    end
  end
end

实际上，我正在使用反射来使其更加健壮，但上面的想法是交叉的。将 WHERE 逻辑移至 JOIN 可确保它不会应用在不适当的地方。 :readonly 选项是为了抵消 Rails 将连接对象设为只读的默认行为。

另外，我知道有些人嘲笑 default_scope 的使用。但对于多租户应用程序来说，它非常适合。