| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
| |
* Use NOT IN in SQL query
* Quote table names propertly
* Use array form of command invocation
|
| |
|
| |
|
|
|
|
|
|
| |
When using `sql` as the schema format, or even just doing `rake
db:structure:dump`, it would be good to respect the list of ignored
tables that has been configured.
|
|
|
|
|
|
| |
Because we don't need to load tasks for DBs that we don't use for the current app.
Also, these Tasks classes load AR::Base in their class level, and so immediately kick :active_record on_load hooks.
This used to happen when we were loading tasks, not when we run a task.
|
|
|
|
|
| |
Set consistent type cast ENV["VERBOSE"]:
ENV["VERBOSE"] is true if it not equal "false"
|
|
|
|
|
|
| |
The database name used in the test would have actually shown this if it
had tried to execute on a real Mysql instead of being stubbed out
(dashes in database names needs quotes).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add stronger assertions to rake migration tasks to make sure the user is providing a numeric VERSION
An empty string was getting converted to version = 0. This would in turn pass the presence check.
Address linting warning
Add test for rake task and refactor code to meet expectations
In particular passing VERSION=0 should not raise an error.
Addressed Comments for PR #28485. Trimmed empty lines + change of wording for error message
Adjust test for change of wording in error message
Change condition to follow rails idioms
|
| |
|
|
|
|
| |
Fixes #28153.
|
|
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
| |
|
|
|
|
|
|
|
|
|
| |
Today `rake db:schema:cache:dump` only supports dumping cache for a
single connection (`ActiveRecord::Base.connection`). This doesn't work
for apps with multiple databases.
This PR makes `DatabaseTasks` to provide an API for dumping schema cache
for any connection.
|
| |
|
| |
|
|
|
|
| |
We try to not try! internally.
|
|
|
|
|
|
|
|
| |
Without this patch it's impossible to pass extra flags to
mysqldump/pg_dump when running `rake db:structure:dump` or `load`
The following config variables (`structure_load_flags` and `structure_dump_flags`)
make it better configurable.
|
| |
|
|
|
|
| |
Follow up to 99cf7558000090668b137085bfe6bcc06c4571dc.
|
|
|
|
|
|
|
|
|
| |
Recently, the Rails team made an effort to keep the source code consistent, using Ruboco
(bb1ecdcc677bf6e68e0252505509c089619b5b90 and below). Some of the case
statements were missed.
This changes the case statements' formatting and is consistent with changes
in 810dff7c9fa9b2a38eb1560ce0378d760529ee6b and db63406cb007ab3756d2a96d2e0b5d4e777f8231.
|
|
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But heredocs was still kept absolute position. This commit aligns
heredocs indentation for consistency.
|
|
|
|
| |
Some case expressions remain, need to think about those ones.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
| |
Where appropriatei, prefer the more concise Regexp#match?,
String#include?, String#start_with?, or String#end_with?
|
|\
| |
| | |
Improve mysqldump
|
| | |
|
|\ \
| | |
| | | |
PostgreSQL: Fix db:structure:load silent failure on SQL error
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The command line flag "-v ON_ERROR_STOP=1" should be used when invoking psql to make sure errors are not suppressed.
Example: psql -v ON_ERROR_STOP=1 -q -f awesome-file.sql my-app-db
Fixes #23818.
|
| | | |
|
|/ /
| |
| |
| |
| | |
Instead of passing a separete name variable, we can make the resolver
merge a name on the config, and use that before creating the Specification.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Follow up to #22543.
|
|/
|
|
|
|
| |
creating all databases mutates the connection pool. This patch restores
the connection pool to the connection spec established before creating
all databases. Fixes #23279
|
|
|
|
|
|
| |
The error message has become a `DISABLE_DATABASE_ENVIRONMENT_CHECK`, modified to match the error message.
ref: https://github.com/rails/rails/blob/master/activerecord/lib/active_record/migration.rb#L161
|
|\
| |
| | |
Prevent destructive action on production database
|
| | |
|
| |
| |
| |
| | |
Discussion: https://github.com/rails/rails/pull/22967#discussion_r49137035
|
| |
| |
| | |
Raise an error when a destructive action is made on a database where the current environment is different from the environment stored in the database.
|
| |
| |
| |
| |
| |
| |
| | |
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`.
|
| |
| |
| |
| | |
Still more to do. Please assist!
|
|/ |
|