为什么 Rails 使用带范围的 where 子句哈希语法向查询添加“OR 1=0”？

Question

我正在进行的项目是在 RDS 上使用 MySQL（特别是 mysql2 gem）。

当我在 where 语句中使用包括范围在内的条件哈希时，我的查询得到了一些奇怪的补充。

User.where(id: [1..5])

和

User.where(id: [1...5])

分别产生以下查询：

SELECT `users`.* FROM `users` WHERE ((`users`.`id` BETWEEN 1 AND 5 OR 1=0))
SELECT `users`.* FROM `users` WHERE ((`users`.`id` >= 1 AND `users`.`id` < 5 OR 1=0))

查询工作得非常好，因为OR FALSE 实际上是一个空操作。我只是想知道为什么 Rails 或 ARel 将这个 sn-p 添加到查询中。

编辑

看起来可以解释的那一行是line 26 in ActiveRecord::PredicateBuilder。那时仍然不知道哈希值如何是empty?，但也许其他人会这样做。

编辑 2

这很有趣。我正在查看 Filip 的评论以了解他为什么这样做，因为这似乎只是一个澄清，但他是正确的 1..5 != [1..5]。前者是从 1 到 5 的包含范围，而后者是一个数组，其第一个元素 是 前者。我尝试将这些放入 ARel where 调用以查看生成的 SQL 并且 OR 1=0 不存在！

User.where(id: 1..5) #=> SELECT "users".* FROM "users"  WHERE ("users"."id" BETWEEN 1 AND 5)
User.where(id: 1...5) #=> SELECT "users".* FROM "users"  WHERE ("users"."id" >= 1 AND "users"."id" < 5)

虽然我仍然不知道为什么ARel 正在添加OR 1=0，这将始终是错误的，并且似乎没有必要。这可能是因为Arrays 和Ranges 的处理方式不同。

Answer 1

严格来说这是一个猜测，因为我在自己的项目中做了类似的事情（虽然我使用了AND 1）。

无论出于何种原因，在生成查询时，始终使用包含无操作的 WHERE 子句比有条件地生成 WHERE 子句更容易。也就是说，如果您不包含任何 where 部分，它将最终生成仍然有效的内容。

另一方面，我不确定它为什么采用这种形式：当我这样做时，我使用1 [<AND (generated code)>...] 它允许任意链接，但我不明白你所看到的如何允许它。尽管如此，我仍然认为这可能是算法代码生成方案的结果。

Answer 2

检查您是否在使用 active_record-acts_as。这就是我的问题。

将下面的行添加到您的 Gemfile：

gem 'active_record-acts_as', :git => 'https://github.com/hzamani/active_record-acts_as.git'

这只会拉取希望修复的最新版本的 Gem。为我工作。

Answer 3

我认为您个人看到了红宝石的副作用。

我认为做你正在做的事情的更好方法是使用

2.0.0-p481@meri :008 > [*1..5]
 => [1, 2, 3, 4, 5]

User.where(id: [*1..5]).to_sql
"SELECT `users`.* FROM `users`  WHERE `users`.`id` IN (1, 2, 3, 4, 5)"

因为这会创建一个数组与一个具有类 Range 的元素 1 的数组。

或

使用显式范围来触发 AREL 中的 BETWEEN。

# with end element, i.e. exclude_end=false
2.0.0-p481@meri :013 > User.where(id: Range.new(1,5)).to_sql
=> "SELECT `users`.* FROM `users`  WHERE (`users`.`id` BETWEEN 1 AND 5)"

# without end element, i.e. exclude_end=true
2.0.0-p481@meri :022 > User.where(id: Range.new(1, 5, true)).to_sql
 => "SELECT `users`.* FROM `users`  WHERE (`users`.`id` >= 1 AND `users`.`id` < 5)"

Answer 4

基于您发现的事实，[1..5] 不是指定范围的正确方法...我发现了 [1..5] 的行为方式。为了到达那里，我首先发现哈希条件中的空数组会产生1=0 SQL 条件：

User.where(id: []).to_sql
# => "SELECT \"users\".* FROM \"users\"  WHERE 1=0"

而且，如果您检查ActiveRecord::PredicateBuilder::ArrayHandler code，您会看到数组值总是被划分为范围和其他值。

ranges, values = values.partition { |v| v.is_a?(Range) }

这解释了为什么在使用非范围值时看不到 1=0。也就是说，从不包含范围的数组中获取1=0 的唯一方法是提供一个空数组，这会产生1=0 条件，如上所示。当所有数组中的所有数组都是一个范围时，您将获得范围条件 (ranges) 并分别执行一个空数组条件 (values)。我的猜测是，这没有充分的理由......只是让它变得比避免它更容易（因为结果集在任何一种方式都是等效的）。如果分区代码更聪明一点，那么它就不必添加额外的空values 数组，并且可以跳过1=0 条件。

至于1=0首先来自哪里...我认为来自数据库适配器，但我找不到确切的位置。但是，我将其称为未能找到记录的尝试。换句话说，WHERE 1=0 永远不会返回任何用户，这比 WHERE id=null 之类的替代 SQL 更有意义，后者将找到任何 id 为 null 的用户（意识到这不是真正正确的 SQL 语法）。这就是我在尝试查找 id 在空集中的所有用户时所期望的（即，我们不要求 nil id 或 null id 或其他任何东西）。所以，在我看来，将1=0 的确切来源作为黑匣子留下一点是可以的。至少我们现在可以推断为什么数组内部的范围会导致它出现！

更新

我还发现，即使直接使用ARel，还是可以得到1=0：

User.arel_table[:id].in([]).to_sql
# => "1=0"

Answer 5

如果您关心控制您生成的查询以及 SQL 语言和数据库功能的全部功能，那么我建议您从 ActiveRecord/Arel 转移到 Sequel。

老实说，ActiveRecord 会给您带来更多的怪癖和令人恼火的时刻，尤其是当您超越简单的杂乱无章的查询时。当你开始愤怒地尝试查询数据时，可能需要在这里和那里连接几个连接表，然后意识到你确实需要连接条件或联合所有类型的查询。

它在查询生成和结果处理方面也明显更快、更可靠，并且更容易组合您想要的查询。与 arel 不同，它还具有您可以实际阅读的真实文档。

我只是希望我早点发现它，而不是坚持使用 rails 默认数据访问层。