Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
All of queries should return correct result even if including large number #30000
Currently several queries cannot return correct result due to incorrect
assert_equal true, Topic.where(id: [1, 9223372036854775808]).exists? assert_equal true, Topic.where.not(id: 9223372036854775808).exists?
The first example is obviously to be true, but currently it returns
assert_equal topics(:first), Topic.where(id: 1..9223372036854775808).find(1)
The second example also should return the object, but currently it
It can be seen from the examples, the queries including large number
Therefore, This change handles
Ugh... I'm sure I was worried about these sorts of cases when we added that rescue
I don't think replacing binds with inline values is the solution, though. It provides a trivial means of blowing out the prepared statement cache, and even in the best case gives a surprise inefficient query.. what was an index lookup is now a full table scan.
If we can't pick out just the known cases, like
build_query_attribute appears to be doing something really implicit. I'd like to see it be made much more explicit, but this seems fine to me overall. The additional test cases make sense.
I would like to see the intent of
build_query_attribute made more clear before this is merged though
This still opens the possibility of 2**N query cache entries for a single query with N integer parameters, but that's far more bounded than infinity. And it avoids wasting database effort on the known-false condition, so that's good.
I agree the current rescues are catching too much, so something must change. If this can fix it while avoiding even more exceptions, so much the better.
This was referenced
Jan 18, 2018
referenced this pull request
Jan 18, 2018