diff options
author | Jon Leighton <j@jonathanleighton.com> | 2013-04-05 12:46:56 +0100 |
---|---|---|
committer | Jon Leighton <j@jonathanleighton.com> | 2013-04-05 13:14:28 +0100 |
commit | 8606a7fbe9367e9ae37ad058dd07f0dd38daf015 (patch) | |
tree | a83a09299de6ccb87a4efcec8d06c2d23c9fa8f8 /railties | |
parent | f029fb07c210dd384f8ad02b5ce8903911c540d3 (diff) | |
download | rails-8606a7fbe9367e9ae37ad058dd07f0dd38daf015.tar.gz rails-8606a7fbe9367e9ae37ad058dd07f0dd38daf015.tar.bz2 rails-8606a7fbe9367e9ae37ad058dd07f0dd38daf015.zip |
Fix scope chaining + STI
See #9869 and #9929.
The problem arises from the following example:
class Project < ActiveRecord::Base
scope :completed, -> { where completed: true }
end
class MajorProject < Project
end
When calling:
MajorProject.where(tasks_count: 10).completed
This expands to:
MajorProject.where(tasks_count: 10).scoping {
MajorProject.completed
}
However the lambda for the `completed` scope is defined on Project. This
means that when it is called, `self` is Project rather than
MajorProject. So it expands to:
MajorProject.where(tasks_count: 10).scoping {
Project.where(completed: true)
}
Since the scoping was applied on MajorProject, and not Project, this
fails to apply the tasks_count condition.
The solution is to make scoping apply across STI classes. I am slightly
concerned about the possible side-effects of this, but no tests fail and
it seems ok. I guess we'll see.
Diffstat (limited to 'railties')
0 files changed, 0 insertions, 0 deletions