| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Fix `COUNT(DISTINCT ...)` with `ORDER BY` and `LIMIT`
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Since #26972, `ORDER BY` is kept if `LIMIT` is presented for
performance. But in most SQL servers (e.g. PostgreSQL, SQL Server, etc),
`ORDER BY` expressions must appear in select list for `SELECT DISTINCT`.
We should not replace existing select list in that case.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A common source of bugs and code bloat within Active Record has been the
need for us to maintain the list of bind values separately from the AST
they're associated with. This makes any sort of AST manipulation
incredibly difficult, as any time we want to potentially insert or
remove an AST node, we need to traverse the entire tree to find where
the associated bind parameters are.
With this change, the bind parameters now live on the AST directly.
Active Record does not need to know or care about them until the final
AST traversal for SQL construction. Rather than returning just the SQL,
the Arel collector will now return both the SQL and the bind parameters.
At this point the connection adapter will have all the values that it
had before.
A bit of this code is janky and something I'd like to refactor later. In
particular, I don't like how we're handling associations in the
predicate builder, the special casing of `StatementCache::Substitute` in
`QueryAttribute`, or generally how we're handling bind value replacement
in the statement cache when prepared statements are disabled.
This also mostly reverts #26378, as it moved all the code into a
location that I wanted to delete.
/cc @metaskills @yahonda, this change will affect the adapters
Fixes #29766.
Fixes #29804.
Fixes #26541.
Close #28539.
Close #24769.
Close #26468.
Close #26202.
There are probably other issues/PRs that can be closed because of this
commit, but that's all I could find on the first few pages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `find_each`, `find_in_batches` and `in_batches` APIs usually operate
on large numbers of records, where it's preferable not to load them all
into memory at once.
If the query cache is enabled, it will hold onto the query results until
the end of the execution context (request/job), which means the memory
used is still proportional to the total number of records. These queries
are typically not repeated, so the query cache isn't desirable here.
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
| |
|
|
|
|
|
| |
The delegation was needed since passing `relation` with
`relation.bound_attributes`. It should use `relation.arel` in that case.
|
|
|
|
|
|
|
|
| |
in `ActiveRecord::Calculations`
`select`, `count`, and `sum` in `Relation` are also `Enumerable` method
that can be passed block. `select` with block already doesn't take
arguments since 4fc3366. This is follow up of that.
|
|
|
|
|
|
| |
The argument of `Arel::SelectManager.new` is `table`, not `engine`.
https://github.com/rails/arel/blob/v8.0.0/lib/arel/select_manager.rb#L10
|
|
|
|
|
|
|
| |
Follow up of #24203.
Since b644964b `ActiveRecord::Relation` includes `Enumerable` so it is
enough to call `super` simply.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a grouped calculation contains a having clause that references a
selected value, we need to include that selected value in the query.
Postgres doesn't support referencing a selected value in a having
clause, but other databases do; we can skip the test on the pg adapter
but run it for the others.
This was fixed before in 9a298a162c16e019fe6971e563e7f4916e86ced6, but
the test coverage was lost in 5a05207d99b7e2678f9b42db2d9ffc21ec2c8c3b.
The fix regressed in 6311975fb3c02f50730fd1e11b8dba8dd9c05306 and was
removed in 97d46c17ea9113b0ce970167f5208c8d9170915c.
|
|
|
|
|
| |
`select_values` is a local variable defined at previous line.
`select_values += select_values` is totally useless.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`DISTINCT` clause is applied inside aggregate function by
`operation_over_aggregate_column` if needed. Unneeded outside aggregate
function.
```ruby
# Before
author.unique_categorized_posts.count
# => SELECT DISTINCT COUNT(DISTINCT "posts"."id") FROM "posts" INNER JOIN "categorizations" ON "posts"."id" = "categorizations"."post_id" WHERE "categorizations"."author_id" = ? [["author_id", 2]]
# After
author.unique_categorized_posts.count
# => SELECT COUNT(DISTINCT "posts"."id") FROM "posts" INNER JOIN "categorizations" ON "posts"."id" = "categorizations"."post_id" WHERE "categorizations"."author_id" = ? [["author_id", 2]]
```
Closes #27615
|
|
|
|
| |
This reverts commit 28977f1fa3d7b15c1608174a165e60b71ddf3995.
|
|
|
|
|
|
|
|
|
| |
If select clause is specified and last column has a column alias,
additional column alias causes a statement invalid.
Add test coverage for counting a single column with NULL values.
Fixes #27676, #27682, and #27705.
|
|
|
|
| |
Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby
|
|
|
|
|
| |
If `limit_value` is presented, records fetching order is very important
for performance. Should not unscope the order in the case.
|
| |
|
|\
| |
| | |
Rename variable name that returning `type_for` to `type` from `column`
|
| |
| |
| |
| |
| |
| | |
`column_for` was changed to `type_for` to return `type` object at
36bd52b4. But variable name is still `column`. It is very confusing.
Rename variable name `column` to `type` for readability.
|
|/
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.
|
|
|
|
| |
For reduce instantiating `Type::Value`.
|
|\
| |
| | |
`pluck` should use `records` (`load_target`) when `loaded?` is true
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current behaviour of checking if there is a LEFT OUTER JOIN arel
node to detect if we are doing eager_loading is wrong. This problem
wasn't frequent before as only some pretty specific cases would add
a LEFT OUTER JOIN arel node. However, the recent new feature
left_outer_joins also add this node and made this problem happen
frequently.
Since in the perform_calculation function, we don't have access to
eager_loading information, I had to extract the logic for the distinct
out to the calculate method.
As I was in the file for left_outer_join tests, I fixed a few that had
bugs and I replaced some that were really weak with something that
will catch more issues.
In relation tests, the first test I changed would have failed if it
had validated the hash returned by count instead of just checking how
many pairs were in it. This is because this merge of join currently
transforms the join node into an outer join node, which then made
count do a distinct. So before this change, the return was
{1=>1, 4=>1, 5=>1}.
|
| | |
|
| | |
|
|/
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When `group` is used in combination with any calculation method, the
resulting hash uses the grouping expression as the key. Currently we're
incorrectly always favoring the type reported by the query, instead of
the type known by the class. This causes differing behavior depending on
whether the adaptor actually gives proper types with the query or not.
After this change, the behavior will be the same on all adaptors -- we
see if we know the type from the class, fall back to the type from the
query, and finally fall back to the identity type.
Fixes #25595
|
|
|
|
|
|
|
|
| |
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
|
| |
|
| |
|
|
|
|
|
| |
This still isn't as separated as I'd like, but it at least moves most of
the burden of alias mapping in one place.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* When tried to use `Company#accounts` test/models/company.rb I got:
```
ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column:
accounts.company_id: SELECT COUNT(*) AS count_all, "companies"."firm_id"
AS companies_firm_id FROM "companies" INNER JOIN "accounts" ON
"accounts"."company_id" = "companies"."id" GROUP BY "companies"."firm_id"
```
* The refactor on Calculations class was just to simplify the code
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #21922
Let `Book(id, author_id)`, `Photo(id, book_id, author_id)` and `Author(id)`
Running `Book.group(:author_id).joins(:photos).count` will produce:
* Rails 4.2 - conflicts `author_id` in both projection and group by:
```sql
SELECT COUNT(*) AS count_all, author_id AS author_id
FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id"
GROUP BY author_id
```
* Master (9d02a25) - conflicts `author_id` only in projection:
```sql
SELECT COUNT(*) AS count_all, author_id AS author_id
FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id"
GROUP BY "books"."author_id"
```
* With this fix:
```sql
SELECT COUNT(*) AS count_all, "books"."author_id" AS books_author_id
FROM "books" INNER JOIN "photos" ON "photos"."book_id" = "books"."id"
GROUP BY "books"."author_id"
```
|
|\
| |
| | |
Allow select using Arel and perform a count
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It allows a query like `User.select(:name).count` to be written
using Arel as `User.select(User.arel_table[:name]).count`.
It exposes the calculations API to accept Arel nodes:
`User.count(User.arel_table[:name])`, `User.sum(User.arel_table[:id])`,
`Account.average(Account.arel_table[:credit_limit])`,
`Account.maximum(Account.arel_table[:credit_limit])` and
`Account.minimum(Account.arel_table[:credit_limit])`.
|
| |
| |
| |
| | |
Column names inserted via `group` have to be qualified with table name.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The focus of this change is to make the API more accessible.
References to method and classes should be linked to make it easy to
navigate around.
This patch makes exzessiv use of `rdoc-ref:` to provide more readable
docs. This makes it possible to document `ActiveRecord::Base#save` even
though the method is within a separate module
`ActiveRecord::Persistence`. The goal here is to bring the API closer to
the actual code that you would write.
This commit only deals with Active Record. The other gems will be
updated accordingly but in different commits. The pass through Active
Record is not completely finished yet. A follow up commit will change
the spots I haven't yet had the time to update.
/cc @fxn
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This removes the following warning.
```
activerecord/lib/active_record/relation/calculations.rb:74: warning: `&' interpreted as argument prefix
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Arguments of `#sum` does not match with other shortcuts methods
(count, average, minimum, and maximum).
This commit fix these two points:
* call `super` with only block arguments
First argument of `super` method, `Enumerable#sum`, is `identity`
and first argument of `AR::Calculations#sum` is `column_name`.
`Enumerable#sum` does not expect `column_name` to be passed.
* Change first argument of `sum` from array arguemnt to single
argument to match other shortcuts methods. When `sum` accept
array arguemnt, user can pass multi arguments and an exception is
raised from `calculate`.
|
|/
|
|
|
|
|
|
| |
as #uniq will be removed from Rails 5.0 as per the Active Support
exception raised:
ActiveSupport::DeprecationException: DEPRECATION WARNING: uniq is
deprecated and will be removed from Rails 5.0 (use distinct instead).
|
|
|
|
|
|
| |
This is to show users that they can chain `.uniq` and `.pluck` to get
the `DISTINCT column` result. They don't have to do `DISTINCT column`
themselves.
|
|
|
|
|
|
|
|
|
|
|
| |
After discussing, we've decided it makes more sense to include it. We're
already forwarding every conflicting method to `to_a`, and there's no
conflation of concerns. `Enumerable` has no mutating methods, and it
just allows us to simplify the code. No existing methods will have a
change in behavior. Un-overridden Enumerable methods will simply
delegate to `each`.
[Sean Griffin & bogdan]
|
|
|
|
|
|
|
|
| |
This matches our behavior in other cases where useful enumerable methods
might have a different definition in `Relation`. Wanting to actually
enumerate over the records in this case is completely reasonable, and
wanting `.sum` is reasonable for the same reason it is on `Enumerable`
in the first place.
|