| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Since #29860, `travel_back` automatically called at the end of the test.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Refactor Active Record configurations
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While the three-tier config makes it easier to define databases for
multiple database applications, it quickly became clear to offer full
support for multiple databases we need to change the way the connections
hash was handled.
A three-tier config means that when Rails needed to choose a default
configuration (in the case a user doesn't ask for a specific
configuration) it wasn't clear to Rails which the default was. I
[bandaid fixed this so the rake tasks could work](#32271) but that fix
wasn't correct because it actually doubled up the configuration hashes.
Instead of attemping to manipulate the hashes @tenderlove and I decided
that it made more sense if we converted the hashes to objects so we can
easily ask those object questions. In a three tier config like this:
```
development:
primary:
database: "my_primary_db"
animals:
database; "my_animals_db"
```
We end up with an object like this:
```
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
```
The configurations setter takes the database configuration set by your
application and turns them into an
`ActiveRecord::DatabaseConfigurations` object that has one getter -
`@configurations` which is an array of all the database objects.
The configurations getter returns this object by default since it acts
like a hash in most of the cases we need. For example if you need to
access the default `development` database we can simply request it as we
did before:
```
ActiveRecord::Base.configurations["development"]
```
This will return primary development database configuration hash:
```
{ "database" => "my_primary_db" }
```
Internally all of Active Record has been converted to use the new
objects. I've built this to be backwards compatible but allow for
accessing the hash if needed for a deprecation period. To get the
original hash instead of the object you can either add `to_h` on the
configurations call or pass `legacy: true` to `configurations.
```
ActiveRecord::Base.configurations.to_h
=> { "development => { "database" => "my_primary_db" } }
ActiveRecord::Base.configurations(legacy: true)
=> { "development => { "database" => "my_primary_db" } }
```
The new configurations object allows us to iterate over the Active
Record configurations without losing the known environment or
specification name for that configuration. You can also select all the
configs for an env or env and spec. With this we can always ask
any object what environment it belongs to:
```
db_configs = ActiveRecord::Base.configurations.configurations_for("development")
=> #<ActiveRecord::DatabaseConfigurations:0x00007fd1acbdf800
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
db_config.env_name
=> "development"
db_config.spec_name
=> "primary"
db_config.config
=> { "adapter"=>"sqlite3", "database"=>"db/development.sqlite3" }
```
The configurations object is more flexible than the configurations hash
and will allow us to build on top of the connection management in order
to add support for primary/replica connections, sharding, and
constructing queries for associations that live in multiple databases.
|
| |
| |
| |
| |
| | |
Without this, `inverse_associations_test.rb` breaks when running in isolation.
https://travis-ci.org/rails/rails/jobs/422266840#L1894-L1899
|
|\ \
| |/
|/| |
Find inverse associations with plural names
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously ActiveRecord couldn't find inverse associations if they were plural, which is a pretty standard use case. This commit changes the behavior to first attempt to find the singular version, then attempt to find the plural version. That makes it work and find plural associations as in the example below:
```
class Post
has_many :comments
end
class Comment
belongs_to :post
end
```
Previously the `:post` association reflection would only attempt to find a `comment` inverse, as opposed to both a `comment` and `comments` inverse.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Issue #27852 reports that when `rails db:create` fails, it causes
leaking of user's DB credentials to $stderr.
We print a DB's configuration hash in order to help users more quickly
to figure out what could be wrong with his configuration.
This commit changes message from
"Couldn't create database for #{configuration.inspect}" to
"Couldn't create '#{configuration['database']}' database. Please check your configuration.".
There are two PRs that fixing it #27878, #27879, but they need a bit more work.
I decided help to finish this and added Author of those PRs credit in this commit.
Since it is a security issue, I think we should backport it to
`5-2-stable`, and `5-1-stable`.
Guided by https://edgeguides.rubyonrails.org/maintenance_policy.html#security-issues
Fixes #27852
Closes #27879
Related to #27878
[Alexander Marrs & bogdanvlviv]
|
|\ \
| | |
| | | |
Finish converting whitelist and blacklist references
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`changes_applied` should be called before continuing around callback
chain. Otherwise the mutation tracker returns old value for methods like
`changed`? or `id_in_database` in around callbacks. Also methods depend
on `id_in_database`, like `update_column`, are not working in
`around_create` callbacks.
```
class Foo < ActiveRecord::Base
around_create :around_create_callback
def around_create_callback
...
yield
p id_in_database # => nil
update_column(:generated_column, generate_value) # silently fails
end
...
end
```
|
| | |
|
|\ \
| |/
|/| |
Add test case to test enum in has_many
|
| |
| |
| |
| |
| |
| | |
There is test in has_one to test enum, but there is no for has_many.
[Rich Chen]
|
|\ \
| |/
|/| |
Prevent deadlocks when waiting for connection from pool.
|
| |
| |
| |
| |
| | |
When a thread that had the load interlock but was blocked waiting to check a connection out of the connection pool but all of the threads using the available connections were blocked waiting to obtain the load interlock an `ActiveRecord::ConnectionTimeoutError` exception was be thrown by the thread waiting for the connection.
When waiting for the connection to check out we should allow loading to proceed to avoid this deadlock.
|
| |
| |
| |
| | |
`Topic` isn't loaded in this test file.
|
|\ \
| | |
| | | |
Omit BEGIN/COMMIT statements for empty transactions
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a transaction is opened and closed without any queries being run, we
can safely omit the `BEGIN` and `COMMIT` statements, as they only exist
to modify the connection's behaviour inside the transaction. This
removes the overhead of those statements when saving a record with no
changes, which makes workarounds like `save if changed?` unnecessary.
This implementation buffers transactions inside the transaction manager
and materializes them the next time the connection is used. For this to
work, the adapter needs to guard all connection use with a call to
`materialize_transactions`. Because of this, adapters must opt in to get
this new behaviour by implementing `supports_lazy_transactions?`.
If `raw_connection` is used to get a reference to the underlying
database connection, the behaviour is disabled and transactions are
opened eagerly, as we can't know how the connection will be used.
However when the connection is checked back into the pool, we can assume
that the application won't use the reference again and reenable lazy
transactions. This prevents a single `raw_connection` call from
disabling lazy transactions for the lifetime of the connection.
|
|\ \ \
| | | |
| | | | |
Stop using Mocha
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Six Mocha calls prove quite resistant to Minitestification. For example,
if we replace
```
ActiveRecord::Associations::HasManyAssociation
.any_instance
.expects(:reader)
.never
```
with `assert_not_called`, Minitest wisely raises
```
NameError: undefined method `reader' for class `ActiveRecord::Associations::HasManyAssociation'
```
as `:reader` comes from a deeply embedded abstract class,
`ActiveRecord::Associations::CollectionAssociation`.
This patch tackles this difficulty by adding
`ActiveSupport::Testing::MethodCallAsserts#assert_called_on_instance_of`
which injects a stubbed method into `klass`, and verifies the number of
times it is called, similar to `assert_called`. It also adds a convenience
method, `assert_not_called_on_instance_of`, mirroring
`assert_not_called`.
It uses the new method_call_assertions to replace the remaining Mocha
calls in `ActiveRecord` tests.
[utilum + bogdanvlviv + kspath]
|
| |/ / |
|
| | |
| | |
| | |
| | | |
https://github.com/rails/rails/issues/31190
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| | | |
| | | | |
Improve tests for ActiveRecord::ConnectionAdapters::ConnectionPool co…
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
configurations.
|
|\ \ \ \
| | | | |
| | | | | |
Improve test case to test enum correctly
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
without define the enum in class “SpecialBook”, any string status will be casted to integer 0. Then the test have no meaning.
[Rich Chen]
|
|/ / / /
| | | |
| | | |
| | | | |
Fixes #33520.
|
|/ / /
| | |
| | |
| | | |
https://travis-ci.org/rails/rails/jobs/417783260#L1173-L1179
|
| | |
| | |
| | |
| | |
| | | |
If `foreign_keys` is fetched before alter table, it couldn't notice
whether foreign keys are broken or not after alter table.
|
|\ \ \
| | | |
| | | |
| | | | |
SQLite3 adapter `alter_table` method restores foreign keys
|
| |/ /
| | |
| | |
| | | |
Related to #33520
|
|\ \ \
| | | |
| | | | |
Fix numericality validator not to be affected by custom getter
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since fe9547b6, numericality validator would parse raw value only when a
value came from user to work type casting to a value from database.
But that was caused a regression that the validator would work against
getter value instead of parsed raw value, a getter is sometimes
customized by people. #33550
There we never guarantees that the value before type cast was going to
the used in this validation (actually here is only place that getter
value might not be used), but we should not change the behavior unless
there is some particular reason.
The purpose of fe9547b6 is to work type casting to a value from
database. We could achieve the purpose by using `read_attribute`,
without using getter value.
Fixes #33550.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Move changelog entry of #33530 up in order to preserve the chronology
since we always add new entries on the top of a changelog file.
- Clarify the changelog entry
- Clarify the docs of remove_foreign_key
- Ensure reversible of `remove_foreign_key` with `:primary_key` and `:to_table`
options.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
remove_foreign_key supports
- remove_foreign_key :accounts, :branches
- remove_foreign_key :accounts, to_table: :branches
but the second one is not reversible.
This branch is to fix and allow second one to be reversible.
[Nikolay Epifanov, Rich Chen]
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
What?
From now on when `accepts_nested_attributes_for` defined and `extend` option
added the overwritten `build` method being called.
[Alireza Bashiri, Martins Polakovs]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
violations on delete
|
| |
| |
| |
| | |
Clean up some concepts in the code while we're here.
|
| |
| |
| |
| | |
source is ignored (#33455)
|