| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
With #31615 `type_for_attribute` accepts either
a symbol as well as a string. `has_attribute?` and `attribute_alias`
also accept either. Since these methods call `to_s` on the argument,
we no longer need to do that at the call site.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't replace existing SELECT list as long as having DISTINCT, it
will cause incorrect result.
And also, PostgreSQL has a limitation that ORDER BY expressions must
appear in select list for SELECT DISTINCT.
Therefore, we should not replace existing SELECT list when using
DISTINCT.
Fixes #29779.
|
|
|
|
| |
We can't replace existing select list as long as referenced by ORDER BY.
|
|
|
|
|
|
|
|
| |
implementation
and defaults to `Digest::MD5`.
Replaced calls to `::Digest::MD5.hexdigest` with calls to `ActiveSupport::Digest.hexdigest`.
|
|
|
|
|
|
| |
is needed
Fixes #30315.
|
|
|
|
|
| |
Because `collection.table_name` doesn't respect table alias.
Use `collection.arel_attribute` instead.
|
|\
| |
| | |
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.
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
`cache_key` includes the size of a relation. But if a relation is not
loadded, the size is not respected even if a relation has a limit. It
should be respected for consistency.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- We don't need the select scope added by user as we only want to max
timestamp and size of the collection. So we already know which columns
to select.
- Additionally having user defined columns in select scope blows the cache_key
method with PostGreSQL because it needs all `selected` columns in the group_by
clause or aggregate function.
- Fixes #23038.
|
|
|
|
|
|
|
| |
- When relations return no result or 0 result then cache_key should
handle it gracefully instead of blowing up trying to access
`result[:size]` and `result[:timestamp]`.
- Fixes #23063.
|
|
|
|
|
|
|
|
|
| |
- Before this patch if we try to find cache_key of a loaded but empty
collection it used to give error because of trying to call `updated_at`
on `nil` value generated by
`collection.max_by(×tamp_column).public_send(timestamp_column)`.
- This commit fixes above error by checking if size is greater than zero
or not.
|
|
|
|
|
|
|
| |
PostgreSQL is strict about the usage of `DISTINCT` and `ORDER BY`, which
one of the tests demonstrated. The order clause is never going to be
relevant in the query we're performing, so let's just remove it
entirely.
|
|
|