| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two concerns which are both being combined into one here, but
both have the same goal. There are certain attributes which we want to
always consider initialized. Previously, they were handled separately.
The primary key (which is assumed to be backed by a database column)
needs to be initialized, because there is a ton of code in Active Record
that assumes `foo.id` will never raise. Additionally, we want attributes
which aren't backed by a database column to always be initialized, since
we would never receive a database value for them.
Ultimately these two concerns can be combined into one. The old
implementation hid a lot of inherent complexity, and is hard to optimize
from the outside. We can simplify things significantly by just passing
in a hash.
This has slightly different semantics from the old behavior, in that
`Foo.select(:bar).first.id` will return the default value for the
primary key, rather than `nil` unconditionally -- however, the default
value is always `nil` in practice.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since #31173, mysql2 adapter depends on `automatic_close` which is
introduced since mysql2 0.4.3. So the adapter with the mysql2 version
before doesn't work with fork now.
```
% ARCONN=mysql2 be ruby -w -Itest test/cases/connection_adapters/connection_handler_test.rb -n test_forked_child_doesnt_mangle_parent_connection
Using mysql2
Run options: -n test_forked_child_doesnt_mangle_parent_connection --seed 19988
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:108:in `discard!': undefined method `automatic_close=' for #<Mysql2::Client:0x00007fedaa91dfd0> (NoMethodError)
```
This drops mysql2 version less than 0.4.3 to guarantee fork safety.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
statement due to user request (#31235)
This changes `StatementTimeout` to `QueryCanceled` for PostgreSQL.
In MySQL, errno 1317 (`ER_QUERY_INTERRUPTED`) is only used when the
query is manually cancelled.
But in PostgreSQL, `QUERY_CANCELED` error code (57014) which is used
`StatementTimeout` is also used when the both case. And, we can not tell
which reason happened.
So I decided to introduce new error class `QueryCanceled` closer to the
error code name.
|
|
|
|
|
|
| |
Since #31129, new error class `StatementTimeout` has been added.
`TransactionTimeout` is caused by the timeout shorter than
`StatementTimeout`, but its name is too generic. I think that it should
be a name that understands the difference with `StatementTimeout`.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Flush idle database connections
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Provide arguments to RecordNotFound
|
| | | |
|
|\ \ \
| | | |
| | | | |
Add :nodoc: to activerecord [ci skip]
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
|\ \ \ \ \
| |_|_|_|/
|/| | | | |
Improve AR connection fork safety
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Use whatever adapter-provided means we have available to ensure forked
children don't send quit/shutdown/goodbye messages to the server on
connections that belonged to their parent.
|
| | | | |
| | | | |
| | | | | |
[ci skip]
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These extra `spawn` are called via `klass.all` and `klass.all` is called
everywhere in the internal. Avoiding the extra `spawn` makes` klass.all`
30% faster for STI classes.
https://gist.github.com/kamipo/684d03817a8115848cec8e8b079560b7
```
Warming up --------------------------------------
fast relation 4.410k i/100ms
slow relation 3.334k i/100ms
Calculating -------------------------------------
fast relation 47.373k (± 5.2%) i/s - 238.140k in 5.041836s
slow relation 35.757k (±15.9%) i/s - 176.702k in 5.104625s
Comparison:
fast relation: 47373.2 i/s
slow relation: 35756.7 i/s - 1.32x slower
```
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Prevent deadlocks with load interlock and DB lock.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This fixes an issue where competing threads deadlock each other.
- Thread A holds the load interlock but is blocked on getting the DB lock
- Thread B holds the DB lock but is blocked on getting the load interlock (for example when there is a `Model.transaction` block that needs to autoload)
This solution allows for dependency loading in other threads while a thread is waiting to acquire the DB lock.
Fixes #31019
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Switch to LIFO for the connection pool
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Using a FIFO for the connection pool can lead to issues when there are
upstream components (pgbouncer, haproxy, etc.) that terminate
connections that are idle after a period of time. Switching to a LIFO
reduces the probability that a thread will checkout a connection that is
about to be closed by an idle timeout in an upstream component.
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | | |
Enable query cache on all connection pools
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Since the query cache no longer eagerly checks out a connection, we can
enable it on all connection pools at the start of every request, and it
will only take effect for requests that actually use those pools.
|
| |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`_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.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* Add a #populate method to migrations
* Address rubocop issues
* Rename to #up_only and use #execute in the examples intead of the model
* Update CHANGELOG
[Rich Daley & Rafael Mendonça França]
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Make it clear that `exists?` can be chained onto a relation
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
Disallow raw SQL in dangerous AR methods
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
with Arel SQL literator which overrides #concat
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | |_|/ / /
| |/| | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Currently the environment is not loaded in some db tasks.
Therefore, if use encrypted secrets values in `database.yml`,
`read_encrypted_secrets` will not be true, so the value can not be
used correctly.
To fix this, added `environment` as dependency of `load_config`.
It also removes explicit `environment` dependencies that are no longer
needed.
Fixes #30717
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The documentation claims that given values go through "normal AR type
casting and serialization", which to me implies
`serialize(cast(value))`, not just serialization. The docs were changed
to use this wording in #22492. The tests I cited in that PR (which is
the same test modified in this commit), is worded in a way that implies
it should be using `cast` as well.
It's possible that I originally meant "normal type casting" to imply
just the call to `serialize`, but given that `update_all(archived:
params['archived'])` seems to be pretty common, I'm inclined to make
this change as long as no tests are broken from it.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Do not use `Arel.star` when `ignored_columns`
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
If there are any ignored columns, we will now list out all columns we
want to be returned from the database.
Includes a regression test.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
timeout exceeded (#31129)
We are sometimes using The MAX_EXECUTION_TIME hint for MySQL depending
on the situation. It will prevent catastrophic performance down by wrong
performing queries.
The new error class `StatementTimeout` will make to be easier to handle
that case.
https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html#optimizer-hints-execution-time
|