| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
I've found the skewness of delegation methods between `except` and
`only` in a88b6f2.
The `only` method is closely similar with `except` as `SpawnMethods`.
https://github.com/rails/rails/blob/e056b9bfb07c4eb3bcc6672d885aadd72bec574f/activerecord/lib/active_record/relation/spawn_methods.rb#L53-L67
It is preferable both behaves the same way.
|
|
|
|
|
|
|
|
|
|
| |
#35360 allows table name qualified if `from` has original table name.
But that is still too strict. We have a valid use case that `from` with
INDEX hint (e.g. `from("comments USE INDEX (PRIMARY)")`).
So I've relaxed the table name detection in `from` to allow any
extension like INDEX hint.
Fixes #35359.
|
|
|
|
| |
https://buildkite.com/rails/rails/builds/59106#596284a1-4692-4640-8a50-c4286e173bbb/115-126
|
|
|
|
|
|
|
|
| |
DISTINCT
When using `select` with `'DISTINCT( ... )'` if you use method `size` on a non loaded relation it overrides the column selected by passing `:all` so it returns different value than count.
This fixes #35214
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
old SQLite3
It seems that the reason why the `test_select_with_subquery_in_from_uses_original_table_name`
does not pass is that the return value of `sqlite3_column_name()` is
wrong due to subquery flattening.
This seems to have been fixed with SQLite 3.20.0(https://sqlite.org/changes.html#version_3_20_0).
But CI uses the old version(maybe 3.11.0), I added `DISTINCT` to avoid
optimization by subquery flattening.
Ref: https://sqlite.org/optoverview.html#flattening
|
|
|
|
| |
Somehow `ENV["BUILDKITE"]` didn't work as expected.
|
|
|
|
|
|
| |
Buildkite as well
https://buildkite.com/rails/rails/builds/58981#2423c707-7c56-4639-a76e-8db4fd1e5cf3/102-111
|
|
|
|
|
|
|
|
|
| |
I'm not sure why the test is failed on Travis, it passed on locally.
I suspect that failure is a bug on SQLite3, so just skip the test for
now, since it was not covered by before.
https://travis-ci.org/rails/rails/jobs/496726410#L1198-L1208
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is caused by 0ee96d1.
Since #18744, `select` columns doesn't be qualified by table name if
using `from`. 0ee96d1 follows that for `pluck` as well.
But people depends that `pluck` columns are qualified even if using
`from`.
So I've fixed that to be qualified if `from` has the original table name
to keep the behavior as much as before.
Fixes #35359.
|
| |
|
|\
| |
| | |
Raise ActiveRecord::IrreversibleOrderError if nulls first/last is not a single ordering argument.
|
| |
| |
| |
| | |
single ordering argument.
|
| |
| |
| |
| | |
This follows up 0ee96d13de29680e148ccb8e5b68025f29fd091c.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
as leaked
This deprecates using class level querying methods if the receiver scope
regarded as leaked, since #32380 and #35186 may cause that silently
leaking information when people upgrade the app.
We need deprecation first before making those.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
kamipo/fix_leaking_scope_on_relation_create"
This reverts commit b67d5c6dedbf033515a96a95d24d085bf99a0d07, reversing
changes made to 2e018361c7c51e36d1d98bf770b7456d78dee68b.
Reason: #35186 may cause that silently leaking information when people
upgrade the app.
We need deprecation first before making this.
|
|
|
|
|
|
|
|
|
| |
Currently custom attributes are always qualified by the table name in
the generated SQL wrongly even if the table doesn't have the named
column, it would cause an invalid SQL error.
Custom attributes should only be qualified if the table has the same
named column.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
callbacks
`relation.create` populates scope attributes to new record by `scoping`,
it is necessary to assign the scope attributes to the record and to find
STI subclass from the scope attributes.
But the effect of `scoping` is class global, it was caused undesired
behavior that pollute all class level querying methods in initialization
block and callbacks (`after_initialize`, `before_validation`,
`before_save`, etc), which are user provided code.
To avoid the leaking scope issue, restore the original current scope
before initialization block and callbacks are invoked.
Fixes #9894.
Fixes #17577.
Closes #31526.
|
|
|
|
| |
This follows up d97980a16d76ad190042b4d8578109714e9c53d0.
|
|
|
|
|
|
|
|
| |
* `#create_or_find_by/!`: add more tests
* Fix docs of `create_or_find_by`
This method uses `find_by!` internally.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The delegation methods to named scope are defined when `method_missing`
is invoked on the relation.
Since #29301, the receiver in the named scope is changed to the relation
like others (e.g. `default_scope`, etc) for consistency.
Most named scopes would be delegated from relation by `method_missing`,
since we don't allow scopes to be defined which conflict with instance
methods on `Relation` (#31179). But if a named scope is defined with the
same name as any method on the `superclass` (e.g. `Kernel.open`), the
`method_missing` on the relation is not invoked.
To address the issue, make the delegation methods to named scope is
generated in the definition time.
Fixes #34098.
|
|
|
|
|
|
|
|
| |
`relations_test.rb`
`persistence_test.rb` and `relations_test.rb` have too many lines, so
I'd like to extract relation around tests to dedicated files before
newly test added.
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to avoid double assignments of nested_attributes for `has_many`
relations during record initialization, nested_attributes in `create_with`
should not be passed into `klass.new` and have them populate during
`initialize_internals_callback` with scope attributes.
However, `create_with` keys should always have precedence over where
clauses, so if there are same keys in both `create_with` and
`where_values_hash`, the value in `create_with` should be the one that's
used.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This restores an ability that `update` with ids on a relation which is
described at https://github.com/rails/rails/issues/33470#issuecomment-411203013.
I personally think that the `update` with two arguments on a relation is
not a designed feature, since that is totally not using a relation
state, and also is not documented.
But removing any feature should not be suddenly happened in a stable
version even if that is not documented.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 9ac7dd4, class level `update`, `destroy`, and `delete` were placed
in the `Persistence` module as class methods.
But `Relation#update` without passing ids which was introduced at #11898
is not a class method, and it was caused the extra scoping regression
#33470.
I moved the relation method back into the `Relation` to fix the
regression.
Fixes #33470.
|
|\
| |
| | |
Add `touch_all` method to `ActiveRecord::Relation`
|
| | |
|
|/
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
|
|
|
| |
Active Record distinct & order #count regression
|
|
|
| |
Add #create_or_find_by to lean on unique constraints
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently `count(:all)` with `distinct` doesn't work correctly because
SELECT list is always replaced to `*` or primary key in that case even
if having custom SELECT list.
And also, PostgreSQL has a limitation that ORDER BY expressions must
appear in select list for SELECT DISTINCT.
Therefore, we should not replace custom SELECT list when using
`count(:all)` with `distinct`.
Closes #31277.
|
| |
|
|
|
|
|
|
| |
Arel doesn't support subselect generation for DELETE unlike UPDATE yet,
but we already have that generation in connection adapters. We can
simply use the subselect generated by that one.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This regression was caused at 213796fb due to polymorphic predicates are
combined by `Arel::Nodes::And`. But I'd like to keep that combined
because it would help inverting polymorphic predicates correctly
(e9ba12f7), and we can collect equality nodes regardless of combined by
`Arel::Nodes::And` (`a AND (b AND c) AND d` == `a AND b AND c AND d`).
This change fixes the regression to collect equality nodes in
`Arel::Nodes::And` as well.
Fixes #31338.
|
|\
| |
| |
| | |
Disallow raw SQL in dangerous AR methods
|
| | |
|
| | |
|
| |
| |
| |
| | |
with Arel SQL literator which overrides #concat
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
https://travis-ci.org/rails/rails/jobs/300163487#L1974
|
| |
| |
| |
| | |
Fixes #21577.
|