| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
To make it easier to construct boundable predicate.
|
|
|
|
|
|
| |
The target object for counter cache is not always determined by the
primary key value on the model. I'd like to extract `update_couters`
onto the `Relation` for the internal use.
|
|
|
|
|
| |
http links will be redirected to the https version, but still better to
just directly link to the https version.
|
|
|
|
|
|
|
|
|
|
| |
Since #29301, delegating to klass methods in the `scope` block would
cause extra scoping by the receiver itself. The extra scoping would
always override intermediate scoping like `unscoped` and caused the
regression #33387. To keep the original scoping behavior, should avoid
the extra scoping in the `scope` block.
Fixes #33387.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`touch` option was added to `increment!` (#27660) and `update_counters`
(#26995). But that option behaves inconsistently with
`Persistence#touch` method.
If `touch` option is passed attribute names, it won't update
update_at/on attributes unlike `Persistence#touch` method.
Due to changed from `Persistence#touch` to `increment!` with `touch`
option, #31405 has a regression that `counter_cache` with `touch` option
which is passed attribute names won't update update_at/on attributes.
I think that the inconsistency is not intended. To get back consistency,
ensure that `touch` option updates update_at/on attributes.
|
| |
|
|\
| |
| | |
Add `touch_all` method to `ActiveRecord::Relation`
|
| | |
|
|/
|
|
|
|
|
| |
The extracted method is used for `CollectionCacheAssociationLoading`,
still not public API.
[ci skip]
|
|
|
|
| |
effect the arel and the arel may already be generated by fresh_when
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Add #create_or_find_by to lean on unique constraints
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
|
|
|
| |
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?
|
|
|
|
|
|
|
|
|
|
| |
`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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
`offset`
Most RDBMS (except SQLite) requires subselect for UPDATE with OFFSET,
but Arel doesn't support executable subselect generation for MySQL's
UPDATE yet. We need to use the subselect generated by the connection
adapter for now, it works well.
Fixes #30148.
|
|
|
|
|
|
|
|
|
|
| |
We need to pass scope attributes to `klass.new` to detect subclass.
Otherwise `subclass_from_attributes` can't detect subclass which is had
in scope attributes.
Fixes #18062.
Closes #18227.
Closes #30720.
|
|
|
|
|
|
|
|
| |
Currently, sanitize methods are private. So need `send` to use from
outside class.
However, sometimes want to use sanitize methods from outside Class when
want to generate SQL including multiple tables like search.
In order to avoid using `send` in such a case, changed methods to public.
|
|
|
|
|
|
|
|
|
|
|
| |
rails/kamipo/ordinal_methods_should_respect_loaded_records"
This reverts commit 0f79ab91150b4cdb6c018530978a3395962c7a02, reversing
changes made to d575f7f2e737739302a0e8210d01c10f5d4e2c35.
This PR philosophically conflicts with #30800 and Matthew thinks we
should hold off merging this until we find concensus. Reverting since
we're about to cut a release for 5.2.
|
|\
| |
| |
| |
| | |
rails/kamipo/ordinal_methods_should_respect_loaded_records
Ordinal methods should respect loaded records
|
| |
| |
| |
| |
| |
| | |
We should reset partially loaded `@offsets` cache when latest records
has loaded because the cache has been staled and it may not be
consistent with latest records.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`_update_record` (#29999)
Currently `_create_record` and `_update_record` in `Persistence` are
creating extra `unscoped` and calling `build_arel` in the relation. But
`compile_insert` and `compile_update` can be done without those
expensive operation for `SelectManager` creation. So I moved the
implementation to `Persistence` to avoid creating extra relation and
refactored to avoid calling `build_arel`.
https://gist.github.com/kamipo/8ed73d760112cfa5f6263c9413633419
Before:
```
Warming up --------------------------------------
_update_record 150.000 i/100ms
Calculating -------------------------------------
_update_record 1.548k (±12.3%) i/s - 7.650k in 5.042603s
```
After:
```
Warming up --------------------------------------
_update_record 201.000 i/100ms
Calculating -------------------------------------
_update_record 2.002k (±12.8%) i/s - 9.849k in 5.027681s
```
30% faster for STI classes.
|
| |
| |
| |
| | |
`CollectionProxy`
|
|/
|
|
|
|
|
|
|
|
| |
eager-loading is needed
If a relation has eager-loading values, `count` and `exists?` works
properly, but `update_all` and `delete_all` doesn't work due to missing
`apply_join_dependency`. It should be applied to work consistently.
Fixes #28863.
|
|
|
|
|
|
|
|
|
| |
parent relation's aliases
Building association scope in join dependency should respect the parent
relation's aliases to avoid using the same alias name more than once.
Fixes #30681.
|
|
|
|
|
| |
This is preparation to respect parent relation's alias tracking for
fixing #30681.
|
|\
| |
| |
| |
| | |
jagthedrummer/jeremy/instrumentation-payload-names
Update payload names for `sql.active_record` instrumentation to be more descriptive.
|
| |
| |
| |
| | |
Fixes #30586.
|
|/
|
|
|
|
|
|
|
|
| |
`Persistence::ClassMethods`
The docs are obviously for class level `update`, `destroy`, and
`delete`. It should be placed in `Persistence::ClassMethods` rather than
`Relation`. And also, these methods are not dependent on relation. So it
is not needed to delegate to `all` (plus, `klass.find` is faster than
`relation.find`).
|
|
|
|
|
|
|
| |
It is only used `primary_key` and `connection` in the internal, so it is
not needed to delegate others to `klass` explicitly.
This doesn't change public behavior because `relation` will delegate
missing method to `klass`.
|
|
|
|
|
|
|
| |
This regression was caused by caa178c1. The block for
`set_inverse_instance` should also be passed to join dependency.
Fixes #30402.
|
|
|
|
| |
Because `to_sql` is public API. I introduced `to_sql_and_binds` internal
API to return SQL and binds.
|
|
|
|
| |
For less duplicated code.
|
|\
| |
| | |
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.
|
| |
|
|
|
|
|
|
|
| |
Since 5c71000, it has lost to be able to unscope `default_scope` in STI
associations. This change will use `.empty_scope?` instead of
`.values.empty?` to regard as an empty scope if only have
`type_condition`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I investigated where `scope_for_create` is reused in tests with the
following code:
```diff
--- a/activerecord/lib/active_record/relation.rb
+++ b/activerecord/lib/active_record/relation.rb
@@ -590,6 +590,10 @@ def where_values_hash(relation_table_name = table_name)
end
def scope_for_create
+ if defined?(@scope_for_create) && @scope_for_create
+ puts caller
+ puts "defined"
+ end
@scope_for_create ||= where_values_hash.merge!(create_with_value.stringify_keys)
end
```
It was hit only `test_scope_for_create_is_cached`. This means that
`scope_for_create` will not be reused in normal use cases. So we can
remove caching `scope_for_create` to respect changing `where_clause` and
`create_with_value`.
|
|\
| |
| | |
Remove unused `@last`, `@order_clause`, and `@join_dependency`
|
| |
| |
| |
| |
| |
| | |
Using `@last` and `@order_clause` was removed at 8bb5274 and 90d1524.
`@join_dependency` was added at b959950 but it is unused in the first
place.
|
|/
|
|
|
|
|
| |
This is related with #27680.
Since `where_values_hash` keys constructed by `where` are string, so we
need `stringify_keys` to `create_with_value` before merging it.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|