Draft: Add Migration to Drop Trace Section Tables
Draft
until re-name is complete. Re-naming the tables first to mitigate the risk of dropping the table.
What does this MR do?
Currently the GitLab application only creates records in the ci_build_trace_sections
table and ci_build_trace_section_names
does not read from those tables. See #32565 (closed). Because these are large un-used tables we want to drop them to free up database space.
!66574 (merged) removes the application code that creates the trace sections as well as any trace section-related code (models and factories). See a summary of why we want to remove this code.
We Re-named the tables first to mitigate the risk of dropping the table.
This MR introduces a migration to drop the tables. The up
method of this migration drops dep_ci_build_trace_section_names
and dep_ci_build_trace_sections
. The down
method of this migration rebuilds the tables with any indexes and constraints. Related issue: #337209 (closed)
Migration Output
up
▶ rake db:migrate
== 20210909202853 DropTablesCiBuildTraceSection: migrating ====================
-- table_exists?(:dep_ci_build_trace_sections)
-> 0.0005s
-- drop_table(:dep_ci_build_trace_sections)
-> 0.0035s
-- table_exists?(:dep_ci_build_trace_section_names)
-> 0.0006s
-- drop_table(:dep_ci_build_trace_section_names)
-> 0.0027s
-- execute("DROP FUNCTION IF EXISTS trigger_91dc388a5fe6()")
-> 0.0012s
== 20210909202853 DropTablesCiBuildTraceSection: migrated (4.1071s) ===========
down
▶ rake db:rollback
== 20210909202853 DropTablesCiBuildTraceSection: reverting ====================
-- table_exists?(:dep_ci_build_trace_section_names)
-> 0.0007s
-- create_table(:dep_ci_build_trace_section_names, {:id=>:serial, :force=>:cascade})
-> 0.0106s
-- table_exists?(:dep_ci_build_trace_sections)
-> 0.0005s
-- create_table(:dep_ci_build_trace_sections, {:id=>false, :primary_key=>[:build_id, :section_name_id], :force=>:cascade})
-> 0.0059s
-- transaction_open?()
-> 0.0000s
-- foreign_keys(:dep_ci_build_trace_sections)
-> 0.0046s
-- execute("ALTER TABLE dep_ci_build_trace_sections\nADD CONSTRAINT fk_19de4e8b30\nFOREIGN KEY (section_name_id)\nREFERENCES dep_ci_build_trace_section_names (id)\nON DELETE CASCADE\nNOT VALID;\n")
-> 0.0020s
-- execute("SET statement_timeout TO 0")
-> 0.0009s
-- execute("ALTER TABLE dep_ci_build_trace_sections VALIDATE CONSTRAINT fk_19de4e8b30;")
-> 0.0022s
-- execute("RESET statement_timeout")
-> 0.0007s
-- transaction_open?()
-> 0.0000s
-- foreign_keys(:dep_ci_build_trace_sections)
-> 0.0028s
-- execute("ALTER TABLE dep_ci_build_trace_sections\nADD CONSTRAINT fk_0ce77d63f1\nFOREIGN KEY (project_id)\nREFERENCES projects (id)\nON DELETE CASCADE\nNOT VALID;\n")
-> 0.0016s
-- execute("ALTER TABLE dep_ci_build_trace_sections VALIDATE CONSTRAINT fk_0ce77d63f1;")
-> 0.0109s
-- transaction_open?()
-> 0.0000s
-- foreign_keys(:dep_ci_build_trace_sections)
-> 0.0027s
-- execute("ALTER TABLE dep_ci_build_trace_sections\nADD CONSTRAINT fk_6ad94e233b\nFOREIGN KEY (build_id)\nREFERENCES ci_builds (id)\nON DELETE CASCADE\nNOT VALID;\n")
-> 0.0016s
-- execute("ALTER TABLE dep_ci_build_trace_sections VALIDATE CONSTRAINT fk_6ad94e233b;")
-> 0.0061s
-- transaction_open?()
-> 0.0000s
-- foreign_keys(:dep_ci_build_trace_section_names)
-> 0.0023s
-- execute("ALTER TABLE dep_ci_build_trace_section_names\nADD CONSTRAINT fk_1927c1a7e2\nFOREIGN KEY (project_id)\nREFERENCES projects (id)\nON DELETE CASCADE\nNOT VALID;\n")
-> 0.0015s
-- execute("ALTER TABLE dep_ci_build_trace_section_names VALIDATE CONSTRAINT fk_1927c1a7e2;")
-> 0.0021s
-- table_exists?(:dep_ci_build_trace_sections)
-> 0.0005s
-- column_exists?(:dep_ci_build_trace_sections, :build_id)
-> 0.0014s
-- column_exists?(:dep_ci_build_trace_sections, :build_id)
-> 0.0010s
-- columns(:dep_ci_build_trace_sections)
-> 0.0012s
-- add_column(:dep_ci_build_trace_sections, "build_id_convert_to_bigint", :bigint, {:default=>0, :null=>false})
-> 0.0013s
== 20210909202853 DropTablesCiBuildTraceSection: reverted (0.1493s) ===========
Does this MR meet the acceptance criteria?
Conformity
-
I have included changelog trailers, or none are needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides. -
This change is backwards compatible across updates, or this does not apply.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) -
I have tested this MR in all supported browsers, or it's not needed. -
I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Security
Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.
- [-] Label as security and @ mention
@gitlab-com/gl-security/appsec
- [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [-] Security reports checked/validated by a reviewer from the AppSec team