| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 drop task fails for a reason other than the database not
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.
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
|
|
|
|
|
|
| |
* Previously the sqlite3 adapter could not "fail" on drop. Now an error
is raised when no file exists.
* Also updates purge to be resilient of drop failures. This is how purge
is expected to behave.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The focus of this change is to make the API more accessible.
References to method and classes should be linked to make it easy to
navigate around.
This patch makes exzessiv use of `rdoc-ref:` to provide more readable
docs. This makes it possible to document `ActiveRecord::Base#save` even
though the method is within a separate module
`ActiveRecord::Persistence`. The goal here is to bring the API closer to
the actual code that you would write.
This commit only deals with Active Record. The other gems will be
updated accordingly but in different commits. The pass through Active
Record is not completely finished yet. A follow up commit will change
the spots I haven't yet had the time to update.
/cc @fxn
|
| |
|
| |
|
|\
| |
| |
| | |
Check mysql structure_load for errors
|
|/
|
|
| |
structure_dump consistent
|
|\
| |
| |
| |
| | |
deivid-rodriguez/fix_undefined_method_error_on_exception
Fix undefined method error on exception
|
| |
| |
| |
| |
| |
| | |
The `error` method is not defined, in general, for exceptions. Instead,
print the exception message. This error was hiding actual meaningful DB
configuration errors. See http://stackoverflow.com/questions/18774463.
|
| |
| |
| |
| | |
Usage was removed in 5c4495538b
|
| |
| |
| |
| | |
database_tasks instead of Migrator
|
|\ \
| |/
|/|
| |
| |
| |
| | |
Add method to run command-line db apps
Conflicts:
activerecord/CHANGELOG.md
|
|/
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
| |
Fixes db:structure:dump when using schema_search_path and PostgreSQL
extensions.
Closes #17157.
|
| |
|
|
|
|
| |
This isn't Seattle.rb, @senny. ;)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #17945
`db:test:prepare` still purges the database to always keep the test
database in a consistent state.
This patch introduces new problems with `db:schema:load`. Prior
to the introduction of foreign-keys, we could run this file against
a non-empty database. Since every `create_table` containted the
`force: true` option, this would recreate tables when loading the schema.
However with foreign-keys in place, `force: true` wont work anymore and
the task will crash.
/cc @schneems
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.
Heredocs have better readability, and with `squish` we can still
produce a single line.
This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.
|
|
|
|
|
|
|
|
|
|
| |
[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.
|
|
|
|
| |
:bomb:
|
|
|
|
| |
This fixes random test failure in migrator_test.rb
|
|
|
|
|
|
|
|
|
|
| |
Using heredoc would enforce line wrapping to whatever column width we decided to
use in the code, making it difficult for the users to read on some consoles.
This does make the source code read slightly worse and a bit more error-prone,
but this seems like a fair price to pay since the primary purpose for these
messages are for the users to read and the code will not stick around for too
long.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The rake tasks and the `DatabaseTakss` adapter classes used to
assume a configuration at some places. This forced the rake
tasks to establish a specific connection before calling into
`load_schema`.
After #15394 this started to cause issues because it could
`purge` the wrong database before loading the schema.
|
|
|
|
|
|
| |
morgoth/fix-automatic-maintaining-test-schema-for-sql-format""
This reverts commit 5c87b5c5248154cf8aa76cce9a24a88769de022d.
|