| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\ |
|
| |
| |
| |
| |
| | |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |\
| | |
| | |
| | | |
Enforce frozen string in Rubocop
|
| | | |
|
| |\ \
| | |/
| |/|
| | | |
Make ActiveSupport frozen-string-literal friendly.
|
| | | |
|
|/ / |
|
| | |
|
|/
|
|
|
|
|
| |
- On Mysql, some command line options that affect option-file handling such as `--no-defaults` have to be passed before any other options
- Modified rails to pass them right after the `mysql` command
- Ref https://dev.mysql.com/doc/refman/5.7/en/option-file-options.html and https://bugs.mysql.com/bug.php?id=83386
- Ref #27437
|
| |
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But heredocs was still kept absolute position. This commit aligns
heredocs indentation for consistency.
|
| |
|
|
|
|
|
| |
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
|
| | |
|
|/
|
|
| |
Follow up to #22543.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| | |
Check mysql structure_load for errors
|
|/
|
|
| |
structure_dump consistent
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
db:structure dump and load
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously this method always established a connection to the test database.
This resulted in buggy behavior when combined with other tasks like
`bin/rake db:schema:load`.
This was one of the reasons why #15394 (22e9a91189af2c4e6217a888e77f22a23d3247d1)
was reverted:
> I’ve replicated it on a new app by the following commands: 1) rails
generate model post:title, 2) rake db:migrate, 3) rake
db:schema:load, 4) rails runner ‘puts Post.first’. The last command
goes boom. Problem is that rake db:schema:load wipes the database,
and then doesn’t actually restore it. This is all on MySQL. There’s
no problem with SQLite.
-- DHH
https://github.com/rails/rails/commit/22e9a91189af2c4e6217a888e77f22a23d3247d1#commitcomment-6834245
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Closes #8079.
I had to rework some of the tests because the mock allowed any arguments
for `connection.exeucte`. I think this is very dangerous as there could
anything be executed without the tests noticing it.
|
|
|
|
|
|
|
|
| |
Closes #9518.
The rake task used to fail silently and left an empty `structure.sql`.
It's confusing for users to get to the root of the problem.
The warning message tells them where to look.
|
|
|
|
|
|
|
|
|
|
| |
exception
We were previously rescuing "nil" when no exception class was found.
This does work in 1.9.3, but does not in 2.0, raising an exception
asking for a class or module to be given to the rescue clause.
Thanks @yahonda for catching this.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
set utf8_unicode_ci collation on latin1 table.
|
|
|
|
| |
charset but encoding.
|
| |
|
|
|
|
| |
The previous implementation had the strange requirement that db/structure.sql contain only CREATE TABLE sql statements, one per table, separated by double newlines. SQLite3 and PostgreSQL database tasks, on the other hand, simply spawn 'sqlite3' and 'psql' binaries to load the file directly. The new implementation follows this and attempts to respect all current MySQL configuration settings.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
In a similar vein to Pat's work on create, drop etc, the db:charset
task is now a one liner in databases.rake
|
| |
|
| |
|
| |
|
|
|