| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Fix #28905
|
|
|
|
|
| |
Add cases to ensure that environment variables VERBOSE and VERSION have
correct typecast.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
since 79887593c18919fed49f441d64236362cb755872, create_all task recreates the connection to AR::Base
which doesn't connect to the in_memory database that is set up for tests
|
|
|
|
|
| |
b8f74860b61782e3b949ade3bb51bff40899e89b provided a nicer version of
`#test_structure_load` but the old version was not removed.
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Make ActiveRecord structure load/dump configurable
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/ |
|
| |
|
|
|
|
|
|
| |
assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message
assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|\
| |
| | |
Improve mysqldump
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| | |
test_migrate_clears_schema_cache_afterward test.
Disable transactions for this test.
Fixes #24391
|
| |
| |
| |
| | |
ActiveRecord::Tasks::DatabaseAlreadyExists before another test happened to make it available
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If postgresql is being used and there are multiple schemas listed on the
`schema_search_path`, then `structure.sql` dumps (triggered by `rake
db:structure:dump` or `config.active_record.schema_format = :sql`) began
failing in Rails 4.2.5.
This is due to the changes made in
https://github.com/rails/rails/pull/17885 The problem is that multiple
schemas were getting getting passed to `Kernel.system` as a single,
space delimited string argument (for example, "--schema=foo
--schema=bar"). However, with the updated array style of calling
`Kernel.system`, these need to be passed as separate arguments (for
example, "--schema=foo", "--schema=bar"). If they get passed as a single
string, then the underlying pg_dump program isn't sure how to interpret
that single argument and you'll get an error reporting: "pg_dump: No
matching schemas were found"
|
|
|
|
|
|
| |
`DEFAULT_CHARSET` and `DEFAULT_COLLATION` in `MySQLDatabaseTasks`
was changed by 322068fe85278ea26e26da6dfd7c5612dab15a72.
This test case also should be changed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit f6ca7e4e75408bc42f515fc7206d6c6ff0dce7c6.
The default collation of utf8 in MySQL is the `utf8_general_ci`, and
this should not be changed. This is because, the better collation in the
all locales is not exists, optimal collation in own application is not
known other than themselves.
The `utf8_unicode_ci` is known as Japanese killer in Japan, there are
serious impacts in search of Japanese.
MySQL implements the `utf8_unicode_ci` according to the Unicode
Collation Algorithm (UCA) described at http://www.unicode.org/reports/tr10/,
but the `utf8_unicode_ci` have only partial support for the UCA, only
primary level key comparison implemented (also known as L1 (Base
characters) comparison).
Because L1 (Base characters) comparison does not distinguish between the
presence or absence of the accent, if distinction of the accent is
important there is a serious impact (e.g. Japanese).
Example:
```
> SHOW CREATE TABLE `dicts`\G
*************************** 1. row ***************************
Table: dicts
Create Table: CREATE TABLE `dicts` (
`word` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`meaning` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
1 row in set (0.00 sec)
> INSERT INTO `dicts` VALUES ('ハハ', 'mother'), ('パパ', 'father');
Query OK, 2 rows affected (0.00 sec)
> SELECT * FROM `dicts` WHERE `word` = 'ハハ';
+--------+---------+
| word | meaning |
+--------+---------+
| ハハ | mother |
| パパ | father |
+--------+---------+
2 rows in set (0.00 sec)
> CREATE UNIQUE INDEX `unique_index_word` ON `dicts`(`word`);
ERROR 1062 (23000): Duplicate entry 'ハハ' for key 'unique_index_word'
```
We should omit the collation entirely rather than providing a default.
Then the choice is the responsibility of the server and MySQL distribution.
|
|
|
|
|
|
|
|
|
|
|
| |
* If the create task fails for a reason other than the database already
existing, processing should end. This is indicated by a non-zero exit
status.
* Since the backtrace is already printed to screen, we forgo printing it
again by using an explicit call to `exit`.
* :warning: This modifies the behavior of the db:create task slightly in
that the stack trace is no longer printed by default. If the `--trace`
option is used, it will print the trace _after_ the error message.
|
|
|
|
| |
Remove deprecated pg_dump -i flag
|
|\
| |
| |
| | |
Check mysql structure_load for errors
|
|/
|
|
| |
structure_dump consistent
|
|
|
|
| |
database_tasks instead of Migrator
|
|
|
|
|
|
|
|
|
|
| |
- Added run_cmd() class method to dry up Kernel.system() messages within
this namespace and avoid shell expansion by passing a list of
arguments instead of a string
- Update structure_dump, structure_load, and related tests units to
pass a list of params instead of using a string to
avoid shell expansion
|
| |
|
|
|
|
| |
db:structure dump and load
|
|
|
|
| |
Avoid loading user's psqlrc when loading test structure
|
|
|
|
|
|
|
| |
Fixes db:structure:dump when using schema_search_path and PostgreSQL
extensions.
Closes #17157.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
[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.
|