aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/finder_respond_to_test.rb
diff options
context:
space:
mode:
authorBen Woosley <ben.woosley@gmail.com>2013-05-14 15:01:20 +0200
committerBen Woosley <ben.woosley@gmail.com>2013-05-14 16:03:17 +0200
commit23c656c1bc113e5f198464ad29d72c5238bfd796 (patch)
tree4dcbee09d374aa64614da8ad9b5f4e81465b71e1 /activerecord/test/cases/finder_respond_to_test.rb
parent010ea715f2a629059117054f8079a5a1f60f30f6 (diff)
downloadrails-23c656c1bc113e5f198464ad29d72c5238bfd796.tar.gz
rails-23c656c1bc113e5f198464ad29d72c5238bfd796.tar.bz2
rails-23c656c1bc113e5f198464ad29d72c5238bfd796.zip
Backport a super-simplified version of #6792, fixing
that #exists? and others can produce invalid SQL: "SELECT DISTINCT DISTINCT" The combination of a :uniq => true association and the #distinct call in #construct_limited_ids_condition combine to create invalid SQL, because we're explicitly selecting DISTINCT, and also sending #distinct on to AREL, via the relation#distinct_value. Where #6792 was the forever fix, this is the minimal fix. Instead of properly indicating the distinctness of the query through #uniq_value alone, we use a literal select statement and set #uniq_value to always be falsey
Diffstat (limited to 'activerecord/test/cases/finder_respond_to_test.rb')
0 files changed, 0 insertions, 0 deletions