Skip to content

Rename ApplicationSetting.database_apdex_settings to be more generic

What does this MR do and why?

Reasoning for this change can be found here.

As per our docs, this MR adds the below steps

  • regular migration to rename_column_concurrently.
  • ignoring the old column in the model.
  • adds a post deployment migration to cleanup_concurrent_column_rename.

Next step: The ignore column from the model will be removed in !128751 (in 16.4 milestone).

Database migration output

RenameApplicationSettingsDatabaseApdexSettings:

main: == 20230808123101 RenameApplicationSettingsDatabaseApdexSettings: migrating ===
main: -- transaction_open?()
main:    -> 0.0000s
main: -- columns(:application_settings)
main:    -> 0.1264s
main: -- column_exists?(:application_settings, :id)
main:    -> 0.1235s
main: -- column_exists?(:application_settings, :prometheus_alert_db_indicators_settings)
main:    -> 0.1228s
main: -- columns(:application_settings)
main:    -> 0.1231s
main: -- add_column(:application_settings, :prometheus_alert_db_indicators_settings, :jsonb, {:limit=>nil, :precision=>nil, :scale=>nil})
main:    -> 0.0010s
main: -- transaction_open?()
main:    -> 0.0000s
main: -- exec_query("SELECT COUNT(*) AS count FROM \"application_settings\"")
main:    -> 0.0020s
main: -- exec_query("SELECT \"application_settings\".\"id\" FROM \"application_settings\" ORDER BY \"application_settings\".\"id\" ASC LIMIT 1")
main:    -> 0.0003s
main: -- exec_query("SELECT \"application_settings\".\"id\" FROM \"application_settings\" WHERE \"application_settings\".\"id\" >= 1 ORDER BY \"application_settings\".\"id\" ASC LIMIT 1 OFFSET 1")
main:    -> 0.0003s
main: -- transaction()
main: -- execute("SELECT set_config('lock_writes.application_settings', 'false', true)")
main:    -> 0.0004s
main: -- execute("UPDATE \"application_settings\" SET \"prometheus_alert_db_indicators_settings\" = \"application_settings\".\"database_apdex_settings\" WHERE \"application_settings\".\"id\" >= 1")
main:    -> 0.0015s
main:    -> 0.0022s
main: -- indexes(:application_settings)
main:    -> 0.0043s
main: -- foreign_keys(:application_settings)
main:    -> 0.0023s
main: -- transaction_open?()
main:    -> 0.0000s
main: -- column_exists?(:application_settings, :database_apdex_settings)
main:    -> 0.1250s
main: -- column_exists?(:application_settings, :prometheus_alert_db_indicators_settings)
main:    -> 0.1247s
main: -- current_schema()
main:    -> 0.0011s
main: -- transaction_open?()
main:    -> 0.0000s
main: -- quote_table_name(:application_settings)
main:    -> 0.0000s
main: -- quote_column_name(:database_apdex_settings)
main:    -> 0.0000s
main: -- quote_column_name(:prometheus_alert_db_indicators_settings)
main:    -> 0.0000s
main: -- columns(:application_settings)
main:    -> 0.1242s
main: -- execute("CREATE OR REPLACE FUNCTION function_for_trigger_5a8a81e3fd20()\nRETURNS trigger\nLANGUAGE plpgsql\nAS $$\nBEGIN\n  IF NEW.\"database_apdex_settings\" IS NOT DISTINCT FROM NULL AND NEW.\"prometheus_alert_db_indicators_settings\" IS DISTINCT FROM NULL THEN\n    NEW.\"database_apdex_settings\" = NEW.\"prometheus_alert_db_indicators_settings\";\n  END IF;\n\n  IF NEW.\"prometheus_alert_db_indicators_settings\" IS NOT DISTINCT FROM NULL AND NEW.\"database_apdex_settings\" IS DISTINCT FROM NULL THEN\n    NEW.\"prometheus_alert_db_indicators_settings\" = NEW.\"database_apdex_settings\";\n  END IF;\n\n  RETURN NEW;\nEND\n$$;\n\nDROP TRIGGER IF EXISTS trigger_5a8a81e3fd20\nON \"application_settings\";\n\nCREATE TRIGGER trigger_5a8a81e3fd20\nBEFORE INSERT ON \"application_settings\"\nFOR EACH ROW EXECUTE FUNCTION function_for_trigger_5a8a81e3fd20();\n")
main:    -> 0.0016s
main: -- execute("CREATE OR REPLACE FUNCTION function_for_trigger_a80eece92991()\nRETURNS trigger\nLANGUAGE plpgsql\nAS $$\nBEGIN\n  NEW.\"database_apdex_settings\" := NEW.\"prometheus_alert_db_indicators_settings\";\n  RETURN NEW;\nEND\n$$;\n\nDROP TRIGGER IF EXISTS trigger_a80eece92991\nON \"application_settings\";\n\nCREATE TRIGGER trigger_a80eece92991\nBEFORE UPDATE OF \"prometheus_alert_db_indicators_settings\" ON \"application_settings\"\nFOR EACH ROW EXECUTE FUNCTION function_for_trigger_a80eece92991();\n")
main:    -> 0.0005s
main: -- execute("CREATE OR REPLACE FUNCTION function_for_trigger_4aefd6ee267c()\nRETURNS trigger\nLANGUAGE plpgsql\nAS $$\nBEGIN\n  NEW.\"prometheus_alert_db_indicators_settings\" := NEW.\"database_apdex_settings\";\n  RETURN NEW;\nEND\n$$;\n\nDROP TRIGGER IF EXISTS trigger_4aefd6ee267c\nON \"application_settings\";\n\nCREATE TRIGGER trigger_4aefd6ee267c\nBEFORE UPDATE OF \"database_apdex_settings\" ON \"application_settings\"\nFOR EACH ROW EXECUTE FUNCTION function_for_trigger_4aefd6ee267c();\n")
main:    -> 0.0004s
main: == 20230808123101 RenameApplicationSettingsDatabaseApdexSettings: migrated (0.8964s) 

CleanupApplicationSettingsDatabaseApdexSettingsRename:

main: == [advisory_lock_connection] object_id: 267080, pg_backend_pid: 54467
main: == 20230808123136 CleanupApplicationSettingsDatabaseApdexSettingsRename: migrating 
main: -- column_exists?(:application_settings, :database_apdex_settings)
main:    -> 0.1249s
main: -- transaction_open?()
main:    -> 0.0000s
main: -- quote_table_name(:application_settings)
main:    -> 0.0000s
main: -- execute("DROP TRIGGER IF EXISTS trigger_5a8a81e3fd20\nON \"application_settings\";\n\nDROP FUNCTION IF EXISTS function_for_trigger_5a8a81e3fd20;\n")
main:    -> 0.0004s
main: -- execute("DROP TRIGGER IF EXISTS trigger_a80eece92991\nON \"application_settings\";\n\nDROP FUNCTION IF EXISTS function_for_trigger_a80eece92991;\n")
main:    -> 0.0003s
main: -- execute("DROP TRIGGER IF EXISTS trigger_4aefd6ee267c\nON \"application_settings\";\n\nDROP FUNCTION IF EXISTS function_for_trigger_4aefd6ee267c;\n")
main:    -> 0.0003s
main: -- remove_column(:application_settings, :database_apdex_settings)
main:    -> 0.0005s
main: == 20230808123136 CleanupApplicationSettingsDatabaseApdexSettingsRename: migrated (0.1304s) 

Note:

db:check-migration job is failing because renaming the column adds the new column at the end of the table.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #421246 (closed)

Edited by Prabakaran Murugesan

Merge request reports

Loading