From 090e737a2806ef502e1a6b069690318eda9286d3 Mon Sep 17 00:00:00 2001 From: Don Browne Date: Tue, 6 Aug 2024 13:33:34 +0100 Subject: [PATCH] fix comment --- .../migrations/000087_migrate_rule_statuses.up.sql | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/database/migrations/000087_migrate_rule_statuses.up.sql b/database/migrations/000087_migrate_rule_statuses.up.sql index 5a5d69f899..95baa71c6a 100644 --- a/database/migrations/000087_migrate_rule_statuses.up.sql +++ b/database/migrations/000087_migrate_rule_statuses.up.sql @@ -21,10 +21,10 @@ BEGIN; -- any rule evaluations which happened before we started dual writing. -- -- As of the previous migration, any entry in rule_evaluations which has a --- corresponding entry in evaluation_rule_entities will have a non-null --- value for the rule_entity_id foreign key. In order to simplify the migration --- this transaction will start off by populating a temporary table with the IDs --- of the rule_evaluation rows which we need to migrate. +-- corresponding entry in evaluation_rule_entities will have the `migrated` +-- column set to `TRUE`. In order to simplify the migration this transaction +-- will start off by populating a temporary table with the IDs of the +-- rule_evaluation rows which we need to migrate. -- -- This table also has an evaluation_status_id which will be populated later. -- This is needed because remediations and alerts in the evaluation history @@ -93,8 +93,6 @@ JOIN evaluation_statuses AS es ON es.id = tmp.evaluation_status_id; -- Set the migrated column in the rows we migrated from -- rule_evaluations. --- Recall that we reused the PK of rule_evaluations as the PK for the new rows --- in evaluation_rule_profiles, so we can simply set rule_entity_id = id. UPDATE rule_evaluations SET migrated = TRUE WHERE id IN (SELECT rule_evaluation_id FROM temp_migrate_rule_evaluations);