H -->|No| I[Post-deploy migration<br/>+ feature flag]
D -->|Yes| F[Post-deploy migration]
D -->|No| G[Background migration]
```
...
...
@@ -256,8 +256,6 @@ lock allow the database to process other statements.
**Removing a column:**
```ruby
includeGitlab::Database::MigrationHelpers
defup
with_lock_retriesdo
remove_column:users,:full_name
...
...
@@ -278,8 +276,6 @@ you should do as much as possible inside the transaction rather than trying to g
Be careful about running long database statements within the block. The acquired locks are kept until the transaction (block) finishes and depending on the lock type, it might block other database operations.
@@ -974,7 +962,7 @@ If you need more complex logic, you can define and use models local to a
migration. For example:
```ruby
classMyMigration<ActiveRecord::Migration[6.0]
classMyMigration<Gitlab::Database::Migration[1.0]
classProject<ActiveRecord::Base
self.table_name='projects'
end
...
...
@@ -1073,7 +1061,7 @@ in a previous migration.
It is important not to leave out the `User.reset_column_information` command, in order to ensure that the old schema is dropped from the cache and ActiveRecord loads the updated schema information.