| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
| |
| |
| |
| |
| | |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes `ActiveRecord::DatabaseTasksUtilsTask#test_raises_an_error_when_called_with_protected_environment`
test fails.
https://travis-ci.org/rails/rails/jobs/238861562
https://travis-ci.org/rails/rails/jobs/239950092
There seems to be an error because `environment` value is not exist.
This is because did not set the environment after recreating the
table in `SchemaMigrationsTest#test_initializes_internal_metadata_for_encoding_utf8mb4`.
Therefore, we create value after the test to maintain the original state.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`internal_string_options_for_primary_key` is used for creating internal
tables in newly apps. But it is no longer needed after MySQL 8.0.0.
MySQL 5.7 has introduced `innodb_default_row_format` (default `DYNAMIC`)
and has deprecated `innodb_large_prefix` and `innodb_file_format`.
The purpose of the deprecated options was for compatibility with earlier
versions of InnoDB.
https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_large_prefix
> innodb_large_prefix is deprecated and will be removed in a future
release. innodb_large_prefix was introduced in MySQL 5.5 to disable
large index key prefixes for compatibility with earlier versions of
InnoDB that do not support large index key prefixes.
https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_file_format
> The innodb_file_format option is deprecated and will be removed in a
future release. The purpose of the innodb_file_format option was to
allow users to downgrade to the built-in version of InnoDB in MySQL 5.1.
Now that MySQL 5.1 has reached the end of its product lifecycle,
downgrade support provided by this option is no longer necessary.
The deprecated options has removed in MySQL 8.0.0. It is no longer
needed to take care newly created internal tables as a legacy format
after MySQL 8.0.0.
Fixes #28730.
|
|
|
|
|
|
| |
`initialize_internal_metadata_table`
These internal initialize methods are no longer used internally.
|
|
|
|
|
| |
This reverts commit 39c77eb1843f79925c7195e8869afc7cb7323682, reversing
changes made to 9f6f51be78f8807e18fc6562c57af2fdbf8ccb56.
|
|
|
|
|
|
|
|
|
|
|
|
| |
`initialize_internal_metadata_table` internal public methods
These internal methods accidentally appeared in the doc, and so almost
useless. It is enough to create these internal tables directly, and
indeed do so in several places.
https://github.com/rails/rails/blob/v5.0.1/activerecord/lib/active_record/schema.rb#L55
https://github.com/rails/rails/blob/v5.0.1/activerecord/lib/active_record/railties/databases.rake#L6
https://github.com/rails/rails/blob/v5.0.1/activerecord/lib/active_record/tasks/database_tasks.rb#L230
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`initialize_schema_migrations_table` is called in every migrations.
https://github.com/rails/rails/blob/v5.0.0.beta1/activerecord/lib/active_record/migration.rb#L1080
https://github.com/rails/rails/blob/v5.0.0.beta1/activerecord/lib/active_record/schema.rb#L51
This means that extra `show variables` is called regardless of the
existence of `schema_migrations` table.
This change is to avoid extra `show variables` if `schema_migrations`
table exists.
|
|
|
|
|
|
|
| |
Mysql has a weird bug where it cannot index a string column of utf8mb4 if it is over a certain character limit. To get compatibility with msql we can add a limit to the key column. 191 characters is a very long key, it seems reasonable to limit across all adapters since using a longer key wouldn't be supported in mysql.
Thanks to @kamipo for the original PR and the test refactoring.
Conversation: https://github.com/rails/rails/pull/23009#issuecomment-171416629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MySQL unicode support is not only `utf8mb4`.
Then, The index length problem is not only `utf8mb4`.
http://dev.mysql.com/doc/refman/5.6/en/charset-unicode.html
SELECT * FROM information_schema.character_sets WHERE maxlen > 3;
+--------------------+----------------------+------------------+--------+
| CHARACTER_SET_NAME | DEFAULT_COLLATE_NAME | DESCRIPTION | MAXLEN |
+--------------------+----------------------+------------------+--------+
| utf8mb4 | utf8mb4_general_ci | UTF-8 Unicode | 4 |
| utf16 | utf16_general_ci | UTF-16 Unicode | 4 |
| utf16le | utf16le_general_ci | UTF-16LE Unicode | 4 |
| utf32 | utf32_general_ci | UTF-32 Unicode | 4 |
+--------------------+----------------------+------------------+--------+
|
|
|
|
|
|
| |
The charset of `version` column in `schema_migrations` table is depend
on the database default charset and collation rather than the encoding
of the connection.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This prevents the following error when a MySQL index on a foreign key
column is renamed:
```
ActiveRecord::StatementInvalid: Mysql2::Error: Cannot drop index 'index_engines_on_car_id': needed in a foreign key constraint: DROP INDEX `index_engines_on_car_id` ON `engines`
```
refs: #13038.
|
|
"utf8mb4"
Please, see rationale in the included CHANGELOG patch.
|