`spec` is the same variable name as gemspec generated by bundler, and its
intention is easier to understand than a one-letter variable.
00fd58eaa6/lib/bundler/templates/newgem/newgem.gemspec.tt (L11)
This is follow up on 1c59b4840c58097186022f68427c46e0046c5d0d. `spec` is already in use there.
Since when we remove one column it will also remove the associated
indexes, we must ensure this behaviour is properly documented.
In this commit we add a line to the documentation mentioning this
behaviour.
Memory before 1826584.8 memory after: 1797795.6 difference: 1.58% memory (speed) savings.
When the key is not longer than the limit we can avoid allocating two strings and an array.
This commit moves the `run_cleanup` hook into an `ensure` block so we
make sure to cleanup the databases even if an exception is raised while
running the parallel tests.
`DatabaseLimits` and those methods were introduced at 3809c80, but most
methods were never used and never tested from the beginning (except
`table_alias_length`, `index_name_length`, and `in_clause_length` (since
66c09372)).
There is no reason to maintain unused those methods for about 8 years.
After #33637 some tests in `activerecord/test/cases/tasks/database_tasks_test.rb`
don't assert anything.
We used to stub `ActiveRecord::Base::configurations` method in those
tests like `ActiveRecord::Base.stub(:configurations, @configurations) {}`.
Since #33637 `ActiveRecord::Base::configurations` is a `ActiveRecord::DatabaseConfigurations`
object(not a Hash object) we can't do so anymore.
`ActiveRecord::DatabaseConfigurations` object builds during `ActiveRecord::Base::configurations=`.
We can replace `ActiveRecord::Base.stub(:configurations, @configurations) {}` to
```
begin
old_configurations = ActiveRecord::Base.configurations
ActiveRecord::Base.configurations = @configurations
# ...
ensure
ActiveRecord::Base.configurations = old_configurations
end
```
Also I fixed tests in `activerecord/test/cases/tasks/legacy_database_tasks_test.rb`
But currently It looks like duplication of
`activerecord/test/cases/tasks/database_tasks_test.rb`.
We should improve those tests or remove them.
I've tried (in `activerecord/test/cases/tasks/legacy_database_tasks_test.rb` file):
```
def with_stubbed_configurations
old_configurations = ActiveRecord::Base.configurations.to_h
ActiveRecord::Base.configurations = @configurations
ActiveRecord::Base.stub(:configurations, ActiveRecord::Base.configurations.to_h) do
yield
end
ensure
ActiveRecord::Base.configurations = old_configurations
end
```
but it causes erros in tests cases.
After discussion we decided to remove
`activerecord/test/cases/tasks/legacy_database_tasks_test.rb`
Related to #33637
The rake tasks which became deprecate now does not load the environment.
Therefore, even if the application specifies the behavior of deprecating,
the message is output to stderr ignoring the specification.
It seems that this is not the expected behavior.
We should respect the setting even in the rake tasks.
Two implemented but undocumented features are to help indicate that cache is fresh for 3 hours, and it may continue to be served stale for up to an additional 60 seconds to parallel requests for the same resource or up to 5 minutes while errors are being returned back while the initial synchronous revalidation is attempted.
These were added for avoiding warnings and for testing in
e4c529ea1d94ef548975e45b91a7fec045aeefbc and 6ea7065a18671872f1486cff3fdaeb4f78fa6332.
Now the default is `:random`, and since the tests added with it are
removed. That config is unnecessary.
Changes the `configs_for` method from using traditional arguments to
using kwargs. This is so I can add the `include_replicas` kwarg without
having to always include `env_name` and `spec_name` in the method call.
`include_replicas` defaults to false because everywhere internally in
Rails we don't want replicas. `configs_for` is for iterating over
configurations to create / run rake tasks, so we really don't ever need
replicas in that case.
