| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 213796f, bind params are used for IN clause if enabled prepared
statements.
Unfortunately, most adapter modules have a limitation for # of bind
params (mysql2 65535, pg 65535, sqlite3 250000). So if eager loading
large number of records at once, that query couldn't be sent to the
database.
Since eager loading/preloading queries are auto-generated by Active
Record itself, so it should be worked regardless of large number of
records like as before.
Fixes #33702.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `Relation::Merger` has a problem that order values would be merged
as nested array.
That was caused an issue #33664 since if array value is passed to
`order` and first element in the array includes `?`, the array is
regarded as a prepared statement and bind variables.
https://api.rubyonrails.org/classes/ActiveRecord/Sanitization/ClassMethods.html#method-i-sanitize_sql_for_order
Just merging that as splat args like other values would fix the issue.
Fixes #33664.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d162188dd662a7d9f62ba8431474f50bc35e3e93, reversing
changes made to 3576782888c307e3e192c44e332b957cd1174128.
Reason: #24131 conflicts the #5153's default order contract, it means
that existing apps would be broken by that change.
We don't want to break existing apps without a deprecation cycle.
|
|
|
|
| |
To make it easier to construct boundable predicate.
|
| |
|
|
|
|
|
| |
In cases where the MatchData object is not used, this provides a speed-up:
https://github.com/JuanitoFatas/fast-ruby/#stringmatch-vs-stringmatch-vs-stringstart_withstringend_with-code-start-code-end
|
| |
|
|
|
|
|
|
|
| |
This reverts commit eb807384c81a6e086b17a576755e992e6c4c685e.
If the current scope is affected by the `unscoped` block, `all` won't be
the same with `spawn`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, column aliases which is used for eager loading are calculated
before constructing all table aliases in FROM clause.
`JoinDependency#join_constraints` constructs table aliases for `joins`
first, and then always re-constructs table aliases for eager loading.
If both `joins` and eager loading are given a same table association,
the re-construction would cause the discrepancy between column aliases
and table aliases.
To avoid the discrepancy, the column aliases should be calculated after
all table aliases are constructed.
Fixes #30603.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If `eager_loading` is true, `apply_join_dependency` force applies
LIMIT/OFFSET before JOINs by `limited_ids_for` to keep parent records
count. But for aggregation queries, LIMIT/OFFSET should be applied after
aggregations the same as SQL semantics.
And also, we could not replace SELECT list by `limited_ids_for` when a
query has a GROUP BY clause. It had never been worked since it will
causes generating invalid SQL for MySQL, PostgreSQL, and probably most
backends.
```
% ARCONN=postgresql be ruby -w -Itest test/cases/calculations_test.rb -n test_group_by_with_limit
Using postgresql
Run options: -n test_group_by_with_limit --seed 20925
# Running:
E
Error:
CalculationsTest#test_group_by_with_limit:
ActiveRecord::StatementInvalid: PG::GroupingError: ERROR: column "posts.id" must appear in the GROUP BY clause or be used in an aggregate function
LINE 1: SELECT DISTINCT "posts"."id", "posts"."type" AS alias_0 FRO... ^
: SELECT DISTINCT "posts"."id", "posts"."type" AS alias_0 FROM "posts" LEFT OUTER JOIN "comments" ON "comments"."post_id" = "posts"."id" GROUP BY "posts"."type" ORDER BY "posts"."type" ASC LIMIT $1
```
Fixes #8103.
Closes #27249.
|
|
|
|
| |
Context: https://github.com/rails/rails/commit/43ef00e5d7a55ad79bc840276d33cb70f1f5dde5#commitcomment-29256140
|
|
|
|
|
|
|
|
|
|
|
| |
Since #26074, introduced force equality checking to build a predicate
consistently for both `find` and `create` (fixes #27313).
But the assumption that only array/range attribute have subtype was
wrong. We need to make force equality checking more strictly not to
allow serialized attribute.
Fixes #32761.
|
|
|
|
|
|
| |
Adds test case for failing issue
Moves set_value back to protected
|
| |
|
|\
| |
| | |
Bring back private class methods accessibility in named scope
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The receiver in a scope was changed from `klass` to `relation` itself
for all scopes (named scope, default_scope, and association scope)
behaves consistently.
In addition. Before 5.2, if both an AR model class and a Relation
instance have same named methods (e.g. `arel_attribute`,
`predicate_builder`, etc), named scope doesn't respect relation instance
information.
For example:
```ruby
class Post < ActiveRecord::Base
has_many :comments1, class_name: "RecentComment1"
has_many :comments2, class_name: "RecentComment2"
end
class RecentComment1 < ActiveRecord::Base
self.table_name = "comments"
default_scope { where(arel_attribute(:created_at).gteq(2.weeks.ago)) }
end
class RecentComment2 < ActiveRecord::Base
self.table_name = "comments"
default_scope { recent_updated }
scope :recent_updated, -> { where(arel_attribute(:updated_at).gteq(2.weeks.ago)) }
end
```
If eager loading `Post.eager_load(:comments1, :comments2).to_a`,
`:comments1` (default_scope) respects aliased table name, but
`:comments2` (using named scope) may not work correctly since named
scope doesn't respect relation instance information. See also 801ccab.
But this is a breaking change between releases without deprecation.
I decided to bring back private class methods accessibility in named
scope.
Fixes #31740.
Fixes #32331.
|
|/
|
|
|
| |
Previously `relation.all` behaves as `relation.scoping { klass.all }`.
But it is just enough to `relation.spawn`.
|
|\
| |
| | |
Use PredicateBuilder for bind params in Relation::Batches
|
| |
| |
| |
| |
| |
| | |
Using the PredicateBuilder to build the bind
attributes allows Batch to drop its dependency on
Relation::QueryAttribute and Arel::Nodes::BindParam
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
This reverts ignoring polymorphic error introduced at 02da8ae.
What the ignoring want to solve was caused by force eager loading
regardless of whether it is necessary, but it has been fixed by #29043.
The ignoring is now only causing a mismatch of `exists?` behavior with
`to_a`, `count`, etc. It should behave consistently.
|
|
|
|
|
|
|
| |
This is an alternative of #29722, and follow up of #32048.
This does not change the current behavior, but makes it easier to modify
all polymorphic names consistently.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The values infinity and -infinity are supported by both date and
timestamp types.
https://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-DATETIME-SPECIAL-TABLE
And also, it can not be known whether a value is infinity correctly
unless cast a value.
I've added `QueryAttribute#infinity?` to handle that case.
Closes #27585.
|
|
|
|
|
| |
Since #32028, Rails 6 requires Ruby 2.3+.
No longer needed workaround for Ruby 2.2 "private attribute?" warning.
|
|
|
|
|
|
| |
This reverts commit cf4f05a7d4a2051cf3593bc7c3a6a216e74e797a.
Since Rails 6 requires Ruby 2.4.1+.
|
| |
|
|\
| |
| |
| |
| | |
mohsen-alizadeh/sanitize_empty_and_nil_parameters_passed_to_select
sanitize empty and nil parameters to select #31059
|
| | |
|
| | |
|
| |
| |
| | |
* Add Relation#pick as short-hand for single-value plucks
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Follow up of #31724.
If `composed_of` objects have multiple mappings, array predicate handler
can not correctly handle the expanded condition.
We need to handle it like polymorphic association objects.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
driving table
This is a regression caused by 6beb4de.
In PostgreSQL, ORDER BY expressions must appear in SELECT list when
using DISTINCT.
When using `count(:all)` with eager loading, Active Record enforces
DISTINCT to count the driving table records only. 6beb4de was caused the
regression because `count(:all)` with DISTINCT path no longer removes
ORDER BY.
We need to ignore ORDER BY when DISTINCT is enforced, otherwise not
always generated valid SQL for PostgreSQL.
Fixes #31783.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Most of the time the table and predicate_builder
passed to Relation.new are exactly the
arel_table and predicate builder of the
given klass. This uses klass.arel_table
and klass.predicate_builder as the defaults,
so we don't have to pass them in most cases.
This does change the signaure of both Relation and
AssocationRelation. Are we ok with that?
|
| | |
|
|\ \
| | |
| | |
| | | |
Allow unscoping of left_outer_joins
|
| | | |
|
| | |
| | |
| | |
| | | |
Because `Relation` already have Arel `table`.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a complete fix to #30995.
Originally alias tracker will only track table aliases on
`Arel::Nodes::Join`, other args are ignored.
Since c5ab6e5, parent aliases hash will be passed then it caused the
regression #30995.
It is enough to pass list of `Arel::Nodes::Join` simply, not need to
pass garbage args which will be ignored.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`find_with_associations`
`find_with_associations` is meaningless name in this point since it just
contain `construct_join_dependency` and `apply_join_dependency`, does
not contain finding anything.
If `apply_join_dependency` returns `relation` and `join_dependency` then
`find_with_associations` is no longer needed.
|
| | |
| | |
| | |
| | |
| | |
| | | |
`relation.exists?` just wants to know if there is a result or not, does
not need the exact records matched. Therefore, an intermediate SELECT
query for eager loading is not necessary.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
We can use `relation.last(index)[-index]` instead of loading all records
when using reversible order because `last` will call `reverse_order`.
|