aboutsummaryrefslogtreecommitdiffstats
path: root/actionview/test/fixtures
diff options
context:
space:
mode:
authorRyuta Kamizono <kamipo@gmail.com>2015-01-13 06:58:27 +0900
committerRyuta Kamizono <kamipo@gmail.com>2015-11-02 20:44:48 +0900
commit322068fe85278ea26e26da6dfd7c5612dab15a72 (patch)
tree9500ccb45c90be7df7627f3cf995d4c68b7b2903 /actionview/test/fixtures
parent10a80e39feb8f5da0ff50f1b04c3f84e7bbbbb54 (diff)
downloadrails-322068fe85278ea26e26da6dfd7c5612dab15a72.tar.gz
rails-322068fe85278ea26e26da6dfd7c5612dab15a72.tar.bz2
rails-322068fe85278ea26e26da6dfd7c5612dab15a72.zip
Remove `DEFAULT_CHARSET` and `DEFAULT_COLLATION` in `MySQLDatabaseTasks`
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.
Diffstat (limited to 'actionview/test/fixtures')
0 files changed, 0 insertions, 0 deletions