| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
test_migrate_clears_schema_cache_afterward test.
Disable transactions for this test.
Fixes #24391
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without clearing the caches afterward, removals done in migrations would
not be reflected in a separate task in the same process. That is, given
a table with a migration to remove a column, the schema cache would
still reflect that a table has that in something such as the
'db:seed' task:
`rake db:migrate db:seed`
(A common thing to do in a script for a project ala `bin/setup`)
vs
`rake db:migrate && rake db:seed`
(Two processes)
The first would not reflect that the column was removed.
The second would (cache reset).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts a334425caff9b2140d5e99fcfc2eb8c4ab10bdfa.
The main reason is that now the workflow is inconsistent when using
spring.
When using spring `RAILS_ENV` is always set, so only one database is
created.
This means that in development `bin/rake db:create` and `bundle exec
rake db:create` have different results.
It also breaks the `bin/setup` script since `bin/rake db:setup
db:test:prepare` will fail.
|
| |\
| |
| | |
Prevent destructive action on production database
|
| | |
| |
| |
| | |
Discussion: https://github.com/rails/rails/pull/22967#discussion_r49137035
|
| | |
| |
| |
| |
| |
| |
| | |
This PR introduces a key/value type store to Active Record that can be used for storing internal values. It is an alternative implementation to #21237 cc @sgrif @matthewd.
It is possible to run your tests against your production database by accident right now. While infrequently, but as an anecdotal data point, Heroku receives a non-trivial number of requests for a database restore due to this happening. In these cases the loss can be large.
To prevent against running tests against production we can store the "environment" version that was used when migrating the database in a new internal table. Before executing tests we can see if the database is a listed in `protected_environments` and abort. There is a manual escape valve to force this check from happening with environment variable `DISABLE_DATABASE_ENVIRONMENT_CHECK=1`.
|
| |/
|
|
| |
Follow up to #22642.
|
| |
|
|
| |
database_tasks instead of Migrator
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
[Joshua Cody & Yves Senn]
Closes #16757.
Prior to this patch schema loading rake tasks had the potential to leak a
connection to a different database. This had side-effects when rake tasks
operating on the current connection (like `db:seed`) were chained.
|
| |
|
|
|
|
| |
This extracts the logic that was embedded in a Rake task into a static
method.
Bonus: the first test for `rake db:migrate`
|
| | |
|
| | |
|
| |
|
|
| |
Closes #13625
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
for an unknown adapter
|
| |
|
|
|
|
|
|
|
|
| |
When running tasks such "rake db:setup", instead of showing messages
like "db_development already exists", it was showing a big stack trace
and a message "Couldn't create database for ..." with the configuration
options, a very confusing message with a big trace.
This brings back the functionality present in 3-2, showing the same
message.
|
| |\
| |
| | |
Allow to register database tasks from different adapters
|
| | | |
|
| |/ |
|
| |
|
