| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
This regression was caused by #23004.
If STI subclass is using scoping in parent class scoping,
`current_scope` in subclass is never restored.
I fixed to restore `current_scope` to previous value correctly.
|
| |
|
|\
| |
| | |
Delegate `ast` and `locked` to `arel` explicitly
|
| |
| |
| |
| |
| |
| |
| |
| | |
Currently `ast` and `locked` are used in the internal but delegating to
`arel` is depend on `method_missing`. If a model class is defined these
methods, `select_all` will be broken.
It should be delegated to `arel` explicitly.
|
|\ \
| | |
| | | |
[ci skip] Changed sentence formation for ActiveRecordRelation#update
|
| |/ |
|
| |
| |
| |
| | |
This was added at #22125 but `left_joins_values` is never used.
|
|/
|
|
| |
Fixes #29025.
|
|
|
|
|
|
|
| |
Instead of loading all records and returning only a subset of those,
just load the records as needed.
Fixes #25537.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The relation method `update_all` allows you to pass a SQL fragment. The
functionality is already mentioned in the prose but the examples section
does not cover it.
|
| |
|
|
|
|
| |
This comment was added at eaf5486 but already implemented.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a parent association was accessed in an `after_find` or
`after_initialize` callback, it would always end up loading the
association, and then immediately overwriting the association we just
loaded. If this occurred in a way that the parent's `current_scope` was
set to eager load the child, this would result in an infinite loop and
eventually overflow the stack.
For records that are created with `.new`, we have a mechanism to
perform an action before the callbacks are run. I've introduced the same
code path for records created with `instantiate`, and updated all code
which sets inverse instances on newly loaded associations to use this
block instead.
Fixes #26320.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The performance difference between `Hash[]` and `Hash.dup` looks to have
been narrowed by @tenderlove via this commit --> https://github.com/ruby/ruby/commit/b3803cc49ad382e23291d75ce57ffb2b74bb9577#diff-eff9999082c8ce7d8ba1fc1d79f439cf.
Since this commit first appeared in Ruby 2.0.0, and since Rails now
requires a minimum Ruby version of 2.2.2, this performance boost should
be available for all users.
Relevant links:
- This behavior was originally added via https://github.com/rails/rails/commit/02174a3efc6fa8f2e5e6f114e4cf0d8a06305b6a
- The conversation on the Ruby issue tracker lives here --> https://bugs.ruby-lang.org/issues/7166
|
|
|
|
|
|
|
|
|
|
| |
Introduced low level methods #set_value and #get_value for setting query attributes:
relation.set_value(:where, {id: 1})
relation.get_value(:includes)
Used those internally when working with relation's attributes
at the abstract level
|
|
|
|
|
|
|
|
|
| |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
|
|
| |
Because causing an extra query by `sql_for_insert` for guessing a
primary key.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/connection_adapters/postgresql/database_statements.rb#L121-L125
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently `exists?` does some hackery where it assumes that we can join
onto anything that we passed to `eager_load` or `includes`, which
doesn't work if we are joining onto a polymorphic association.
Actually figuring out if we want to include something would require
knowledge deep within the join dependency module, which is hard to pull
up. The simplest solution is just to pass a flag down that says we're
not actually going to try to eager load any of the data. It's not the
solution I'd like, but that code really needs to be untangled before we
can do much with it.
This is another attempt at 6d5b1fd which should address the concerns
that led to reverting it in 4ecabed.
|
|
|
|
|
|
|
|
|
|
| |
- we are ending sentences properly
- fixing of space issues
- fixed continuity issues in some sentences.
Reverts https://github.com/rails/rails/commit/8fc97d198ef31c1d7a4b9b849b96fc08a667fb02 .
This change reverts making sure we add '.' at end of deprecation sentences.
This is to keep sentences within Rails itself consistent and with a '.' at the end.
|
|\
| |
| | |
enhance ActiveRecord#substitute_values to loop values just once
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`prefetch_primary_key?` and `next_sequence_value` methods live in the
connection level at the moment, that make sense when you are generating
the sequence from the database, in the same connection. Which is the use
case today at the Oracle and Postgres adapters.
However if you have an service that generates IDs, that has nothing to
do with the database connection, and should not be fetched from there.
Another use case, is if you want to use another connection to fetch IDs,
that would not be possible with the current implementation, however when
we move those methods to the model level, you can use a new connection
there.
Also this makes easier for gems to add behavior on those methods.
|
|
|
|
|
|
| |
Clarifying this separation and enforcing relation immutability is the
culmination of the previous efforts to remove the mutator method
delegations.
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
| |
Arel handles substitution for bind parameters by now.
|
| |
|
|
|
|
| |
Reapply #22615.
|