| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
See https://github.com/rails/rails/commit/da9b5d4a8435b744fcf278fffd6d7f1e36d4a4f2#commitcomment-3630064 for discussion.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| | |
Rather than raising ThrowResult when construct_limited_ids_conditions comes up empty, set the relation to NullRelation and rely on its results.
|
| |
| |
| |
| |
| |
| | |
up empty, set the relation to NullRelation and rely on its results.
This will help avoid errors like 2fcafee250ee2, because in most cases NullRelation will do the right thing. Minor bonus is avoiding the use of exceptions for flow control.
|
| |
| |
| |
| | |
failing to construct_limited_ids_condition.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using symbol keys, ActiveRecord will now translate aliased attribute names to the actual column name used in the database:
With the model
class Topic
alias_attribute :heading, :title
end
The call
Topic.where(heading: 'The First Topic')
should yield the same result as
Topic.where(title: 'The First Topic')
This also applies to ActiveRecord::Relation::Calculations calls such as `Model.sum(:aliased)` and `Model.pluck(:aliased)`.
This will not work with SQL fragment strings like `Model.sum('DISTINCT aliased')`.
Github #7839
*Godfrey Chan*
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb
activerecord/test/cases/adapter_test.rb
guides/source/testing.md
[ci skip]
|
| |
| |
| |
| | |
the only pluck query that translates into the aforementioned SQL
|
| |
| |
| |
| |
| |
| |
| | |
We moved more and more away from passing options to finder / calculation
methods. The `:distinct` option in `#count` was one of the remaining places.
Since we can now combine `Relation#distinct` with `Relation#count` the option
is no longer necessary and can be deprecated.
|
|/
|
|
|
|
|
|
| |
The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our
Relation API is close to SQL terms I renamed `#uniq` to `#distinct`.
There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue
to work. I also updated the documentation to promote the use of `#distinct`.
|
| |
|
| |
|
|
|
|
| |
closes #6865
|
|
|
|
|
| |
This reverts commit 637a7d9d357a0f3f725b0548282ca8c5e7d4af4a, reversing
changes made to 5937bd02dee112646469848d7fe8a8bfcef5b4c1.
|
| |
|
|
|
|
|
|
| |
* dependencies/autoload
* concern
* deprecation
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
skip]
|
|
|
|
|
|
|
| |
To perform a sum calculation over the array of elements, use to_a.sum(&block).
Please check the discussion in f9cb645dfcb5cc89f59d2f8b58a019486c828c73
for more context.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit f9cb645dfcb5cc89f59d2f8b58a019486c828c73.
Conflicts:
activerecord/CHANGELOG.md
Revert "Allow blocks for count with ActiveRecord::Relation. Document and test that sum allows blocks"
This reverts commit 9cc2bf69ce296b7351dc612a8366193390a305f3.
Conflicts:
activerecord/lib/active_record/relation/calculations.rb
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
actionpack/lib/action_dispatch/routing/redirection.rb
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
| |
Closes #7551
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fix build issue with postgresql.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Execute_grouped_calculation is one of those places where
ActiveRecord forgets that it has ARel underpinnings, and
assumes that the values provided to group_values are
strings. This artificially hobbles otherwise functional
code. This patch stops assuming that incoming values
respond to to_sym, stops using string interpolation for
table aliases on objects that support aliasing, and stops
unnecessarily joining group_values on the relation.
Additionally, it calls to_sql, if available, on objects
sent to column_alias_for, in order to get a more reasonable
alias string than a non-string's default to_str method.
|
| |
|