gitlab-org--gitlab-foss

Commit Graph

Author	SHA1	Message	Date
Jan Provaznik	0fc9f9d3e7	Add version 4.2 to all existing migrations DB schema generated by a migration may look different in rails 4 and 5 (because rails 5 may use different default values). For this reason it's important to explicitly set for which rails version a migration was written for. See https://stackoverflow.com/questions/35929869/activerecordmigration-deprecation-warning-asks-for-rails-version-but-im-no/35930912#35930912	2018-11-22 13:18:28 +01:00
Timothy Andrew	eb434b15eb	Make `ChangePersonalAccessTokensDefaultBackToEmptyArray` a "post" migration. If we leave this as a regular migration, we could have the following flow: 1. Application knows nothing about scopes. 2. First migration runs, all existing personal access tokens have `api` scope 3. Application still knows nothing about scopes. 4. Second migration runs, all tokens created after this point have no scope 5. Application still knows nothing about scopes. 6. Tokens created at this time _should have the API scope, but instead have no scope_ 7. Application code is reloaded, application knows about scopes 8. Tokens created after this point only have no scope if the user deliberately chooses to have no scopes. Point #6 is the problem here. To avoid this, we move the second migration to a "post" migration, which runs after the application code is deployed/reloaded.	2016-12-16 16:29:33 +05:30

Author

SHA1

Message

Date

Jan Provaznik

0fc9f9d3e7

Add version 4.2 to all existing migrations

DB schema generated by a migration may look different in
rails 4 and 5 (because rails 5 may use different default values).
For this reason it's important to explicitly set for which rails
version a migration was written for.

See https://stackoverflow.com/questions/35929869/activerecordmigration-deprecation-warning-asks-for-rails-version-but-im-no/35930912#35930912

2018-11-22 13:18:28 +01:00

Timothy Andrew

eb434b15eb

Make `ChangePersonalAccessTokensDefaultBackToEmptyArray` a "post" migration.

If we leave this as a regular migration, we could have the following flow:

1. Application knows nothing about scopes.
2. First migration runs, all existing personal access tokens have `api` scope
3. Application still knows nothing about scopes.
4. Second migration runs, all tokens created after this point have no scope
5. Application still knows nothing about scopes.
6. Tokens created at this time _should have the API scope, but instead have no scope_
7. Application code is reloaded, application knows about scopes
8. Tokens created after this point only have no scope if the user deliberately
   chooses to have no scopes.

Point #6 is the problem here. To avoid this, we move the second migration to a
"post" migration, which runs after the application code is deployed/reloaded.

2016-12-16 16:29:33 +05:30

2 Commits