This project is archived and is in readonly mode.
default_scope treats hashes and relations inconsistently when overwriting
-
Neeraj Singh
In the first test case where relation is being passed the sql query is being built something like this.
> us = User.unscoped; > us=us.merge(User.where(:name => 'David')); > us=us.merge(User.where(:name => 'Jamis')); > us.to_sql => "SELECT \"users\".* FROM \"users\" WHERE (\"users\".\"name\" = 'Jamis')"
In the second case where hash is being passed the sql query is being built something like this.
> us = User.unscoped; > us = us.where(:name => 'David'); > us = us.where(:name => 'Jamis'); > us.to_sql => "SELECT \"users\".* FROM \"users\" WHERE (\"users\".\"name\" = 'David') AND (\"users\".\"name\" = 'Jamis')"
Before I suggest a fix, I would like to know what direction to proceed.
Based on ticket #4583 Merge default scopes by default I should assume that the desired behavior should be the second sql so that one can pass more than one default_scope and all the conditions passed should be ANDed to build the final sql.
-
David Chelimsky
I would expect the same column to get ORed (an IN clause) and different columns to get ANDed:
user = User.unscoped user = user.where(:name => 'David') user = user.where(:name => 'Jamis') user = user.where(:role => 'admin') user.to_sql => SELECT \"users\".* FROM \"users\" WHERE (\"users\".\"name\" in ('David','Jamis')) AND (\"users\".\"role\" = 'admin')Agree?
-
Santiago Pastorino
+1 Agree! i will try a fix
-
Santiago Pastorino
- Milestone cleared.
- Tag changed from activerecord, bug to activerecord, bug, bugmash
- State changed from new to open
- Assigned user changed from José Valim to Santiago Pastorino
-
Santiago Pastorino
Test added here, i don't know if we should test this kind of things or fix in Arel and rely on his behavior.
Anyways i add the test case only for now.
I'm going to patch it. -
Neeraj Singh
- Tag changed from activerecord, bug, bugmash to activerecord, bug, bugmash, patch
Attached is a code patch.
@Santiago thanks for the test.
-
Rohit Arondekar
- Importance changed from to Low
The test still fails in 3-0-stable.
1) Failure: test_find_all_using_where_twice_should_or_the_relation(RelationTest) [test/cases/relations_test.rb:655]: <[#<Author id: 1, name: "David", author_address_id: 1, author_address_extra_id: 2>]> expected but was <[]>.However the patch provided by Neeraj doesn't apply any more so I couldn't check if it solves the problem.
-
Rohit Arondekar
I applied Neeraj's patch manually and it made the test pass. Here is a combined patch for 3-0-stable with both the test and fix. Tests are passing.
-
Santiago Pastorino
- Milestone changed from 3.0.2 to 3.1
- Assigned user changed from Santiago Pastorino to Aaron Patterson
-
Repository
- State changed from open to resolved
(from [fdc591351e5a231c4da47a4b363e961ae89cc864]) collapsing same table / column WHERE clauses to be OR [#4598 default_scope treats hashes and relations inconsistently when overwriting state:resolved] https://github.com/rails/rails/commit/fdc591351e5a231c4da47a4b363e9...
-
Repository
(from [00693209ecc222842949d7cab076f89890cbd507]) collapsing same table / column WHERE clauses to be OR [#4598 default_scope treats hashes and relations inconsistently when overwriting state:resolved] https://github.com/rails/rails/commit/00693209ecc222842949d7cab076f...
-
Jeremy Kemper
- State changed from resolved to open
- Milestone changed from 3.1 to 3.0.5
http://groups.google.com/group/rubyonrails-core/browse_thread/threa...
This inconsistency seems ok in context: second hash condition overwrites the first, whereas the second .where relation ANDs on to it.
-
David Chelimsky
FWIW, I think that having to know that the .where and conditions work differently is confusing and puts an unnecessary burden on users, even if everything is visible in the same context. In our case, we broke the behavior of a gem by adding conditions to the default scope in a model, so we didn't have all the context in one place. Having conditions and .where work differently made it all the more confusing, which is why I submitted this ticket in the first place.
-
Aaron Patterson
- Milestone changed from 3.0.5 to 3.1
I think what we need to do is change this to do an AND in both cases for Rails 3.1. I don't like that we change it to an OR when combining only certain columns. It's like we're tying to read the user's mind, and I am terrible at mind reading.
