From bdfc622526fc6c105a723f97abe27e7a53aa4cac Mon Sep 17 00:00:00 2001 From: Jonathan Smith Date: Mon, 29 Nov 2021 15:45:14 -0500 Subject: [PATCH] Update remove_column docs for how indexes are changed Different databases have different behaviour when it comes to dropping a column that is part of a composite indexes. For example, MySQL and OracleDB will simply remove the column from the index. However PostgresQL will remove any index that is using that column. --- .../connection_adapters/abstract/schema_statements.rb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb b/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb index 96040785a08c3..770b57c447512 100644 --- a/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb +++ b/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb @@ -656,7 +656,8 @@ def remove_columns(table_name, *column_names, type: nil, **options) # The +type+ and +options+ parameters will be ignored if present. It can be helpful # to provide these in a migration's +change+ method so it can be reverted. # In that case, +type+ and +options+ will be used by #add_column. - # Indexes on the column are automatically removed. + # Depending on the database you're using, indexes using this column may be + # automatically removed or modified to remove this column from the index. # # If the options provided include an +if_exists+ key, it will be used to check if the # column does not exist. This will silently ignore the migration rather than raising