| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
We sometimes say "✂️ newline after `private`" in a code review (e.g.
https://github.com/rails/rails/pull/18546#discussion_r23188776,
https://github.com/rails/rails/pull/34832#discussion_r244847195).
Now `Layout/EmptyLinesAroundAccessModifier` cop have new enforced style
`EnforcedStyle: only_before` (https://github.com/rubocop-hq/rubocop/pull/7059).
That cop and enforced style will reduce the our code review cost.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rails has some support for multiple databases but it can be hard to
handle migrations with those. The easiest way to implement multiple
databases is to contain migrations into their own folder ("db/migrate"
for the primary db and "db/seconddb_migrate" for the second db). Without
this you would need to write code that allowed you to switch connections
in migrations. I can tell you from experience that is not a fun way to
implement multiple databases.
This refactoring is a pre-requisite for implementing other features
related to parallel testing and improved handling for multiple
databases.
The refactoring here moves the class methods from the `Migrator` class
into it's own new class `MigrationContext`. The goal was to move the
`migrations_paths` method off of the `Migrator` class and onto the
connection. This allows users to do the following in their
`database.yml`:
```
development:
adapter: mysql2
username: root
password:
development_seconddb:
adapter: mysql2
username: root
password:
migrations_paths: "db/second_db_migrate"
```
Migrations for the `seconddb` can now be store in the
`db/second_db_migrate` directory. Migrations for the primary database
are stored in `db/migrate`".
The refactoring here drastically reduces the internal API for migrations
since we don't need to pass `migrations_paths` around to every single
method. Additionally this change does not require any Rails applications
to make changes unless they want to use the new public API. All of the
class methods from the `Migrator` class were `nodoc`'d except for the
`migrations_paths` and `migrations_path` getter/setters respectively.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| | |
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.
|
