Wait, so what exactly is the situation that's at issue here? We upgraded yesterday, too, and have both scopes and class methods that we append onto has_many/belongs_to relations, but haven't experienced anything out of the ordinary. Now I'm terrified we have some unexpected behavior lurking somewhere that's not tested or something.
> In this case, when using the scope method to define an Arel scope on Organization, the where clause of the scope is overriding the condition imposed by the Organization#teams association. The part of the WHERE clause meant to restrict the query to Team records related to the Acme organization was dropped.
This doesn't happen in all cases -- all the cases where I've done this appears to be fine. And a scope just blowing away an association in all cases would be too obvious to not be caught.
Is it because both the scope and the relation select by the same attribute? Does that attribute have to be `id` for this bug to occur?
Or does it have to do with the fact that they're nesting a query within the where clause to determine the IDs? (I don't see why this would matter).
I guess I'm off to a REPL unless anyone here knows more concretely what the issue is.
EDIT TO ADD:
I can't reproduce this behavior. I just spun up a new Rails 3.2.13 app, and created those two models. Going through what they do in the console, my results differ on the potentially dangerous part:
1.9.3-p0 :015 > teams = acme.teams.using_octocats_scope
Team Load (0.3ms) SELECT "teams".* FROM "teams"
WHERE "teams"."organization_id" = 2
AND "teams"."organization_id" IN
(SELECT id FROM "organizations"
WHERE "organizations"."has_octocats" = 't')
=> []
I do get an empty array, as is supposed to be the case. I notice that my nested select remains a SQL statement, rather than being evaluated to '(1)' as in their example.
So... I don't know if I'm doing something wrong, or if GitHub has other code / configuration settings interacting strangely here.
SELECT "projects". FROM "projects" WHERE "projects"."user_id" = 1 AND "projects"."user_id"=5
This expected SQL doesn't really make sense to me. It would be better if your example didn't include selecting twice on the same column (not a join) with an equals clause, as I'd expect that to be removed (it's redundant and would always produce zero results). So the resulting sql makes more sense (replace where clause when new where clause uses same col):
SELECT "projects". FROM "projects" WHERE "projects"."user_id" = 5*
Looking at the github example, they used xx=1 AND xx IN(1,2,3), which makes more sense as it could possibly produce results, and I see why they were doing that.
I realize those two conditions ensure the query will never return results, but the point is to let you combine business conditions at a higher level of abstraction, which may indeed result in zero results. There are many cases where this sort of thing is useful, and it's important that the conditions be cumulative.
Yeah, very strange. I saw your comment so I decided to put mine on github, too.
https://github.com/losvedir/test_github_thing
I'm going to bed now, so I can't really compare mine to GitHub's to yours right now, but it seems to me that sometimes it's a problem and sometimes not. I dunno...
I can reproduce it reliably by first following a has_many relationship, then adding a scope to that. Adding a where clause (directly or inside of a class method like in Github's example: it's the same thing) is okay. Also the scope must filter on the same column as the foreign key. So this wouldn't cause a problem: `scope :recent, lambda { where("created_at > ?", Time.now.utc - 1.week) }`.
> In this case, when using the scope method to define an Arel scope on Organization, the where clause of the scope is overriding the condition imposed by the Organization#teams association. The part of the WHERE clause meant to restrict the query to Team records related to the Acme organization was dropped.
This doesn't happen in all cases -- all the cases where I've done this appears to be fine. And a scope just blowing away an association in all cases would be too obvious to not be caught.
Is it because both the scope and the relation select by the same attribute? Does that attribute have to be `id` for this bug to occur?
Or does it have to do with the fact that they're nesting a query within the where clause to determine the IDs? (I don't see why this would matter).
I guess I'm off to a REPL unless anyone here knows more concretely what the issue is.
EDIT TO ADD:
I can't reproduce this behavior. I just spun up a new Rails 3.2.13 app, and created those two models. Going through what they do in the console, my results differ on the potentially dangerous part:
I do get an empty array, as is supposed to be the case. I notice that my nested select remains a SQL statement, rather than being evaluated to '(1)' as in their example.So... I don't know if I'm doing something wrong, or if GitHub has other code / configuration settings interacting strangely here.
Can anyone else reproduce?
EDIT AGAIN:
Here are the four files you need to reproduce yourself. https://gist.github.com/losvedir/5202121
ONE MORE EDIT:
https://github.com/losvedir/test_github_thing
There's a repo with my history in the console. Dunno why I'm seeing the behavior I am.