aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/scoping
Commit message (Collapse)AuthorAgeFilesLines
* calling default_scope without a proc will raise ArgumentErrorNeeraj Singh2013-07-021-3/+2
| | | | Calling default_scope without a proc will now raise `ArgumentError`.
* remove deprecated implicit join references.Yves Senn2013-06-291-5/+0
|
* Simplify/fix implementation of default scopesJon Leighton2013-06-281-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous implementation was necessary in order to support stuff like: class Post < ActiveRecord::Base default_scope where(published: true) scope :ordered, order("created_at") end If we didn't evaluate the default scope at the last possible moment before sending the SQL to the database, it would become impossible to do: Post.unscoped.ordered This is because the default scope would already be bound up in the "ordered" scope, and therefore wouldn't be removed by the "Post.unscoped" part. In 4.0, we have deprecated all "eager" forms of scopes. So now you must write: class Post < ActiveRecord::Base default_scope { where(published: true) } scope :ordered, -> { order("created_at") } end This prevents the default scope getting bound up inside the "ordered" scope, which means we can now have a simpler/better/more natural implementation of default scoping. A knock on effect is that some things that didn't work properly now do. For example it was previously impossible to use #except to remove a part of the default scope, since the default scope was evaluated after the call to #except.
* Delegate #unscope query methodCarlos Antonio da Silva2013-04-281-0/+10
|
* Fix scope chaining + STIJon Leighton2013-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* failing test for #9869Neeraj Singh2013-04-051-0/+5
|
* split relation_scoping_test.rb's default scoping tests into another fileTakehiro Adachi2013-03-302-357/+360
|
* rename named_scope_test.rb to a proper file nameTakehiro Adachi2013-03-301-1/+1
| | | | | The file name should be name_scoping_test.rb and the class should be `NamedScopingTest` according to ActiveRecord::Scoping::Name
* move tests for NamedScope and DefaultScope under test/cases/scoping/Takehiro Adachi2013-03-302-0/+1150
The scoping/default.rb and scoping/named.rb got moved under scoping/ in commit 2b22564c4efaa63d4bbc006762838c4025c1bdca, but the tests never did.