From 2b87d22ad415f26794a68022199bcd7dd5af1569 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fredrik=20Adel=C3=B6w?= Date: Wed, 11 Mar 2026 16:19:19 +0100 Subject: [PATCH] Update plugins/catalog-backend/migrations/20260214000000_search_fk_final_entities.js MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Fredrik Adelöw --- .../20260214000000_search_fk_final_entities.js | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/plugins/catalog-backend/migrations/20260214000000_search_fk_final_entities.js b/plugins/catalog-backend/migrations/20260214000000_search_fk_final_entities.js index 4e1fc53d24..4d43baf9a8 100644 --- a/plugins/catalog-backend/migrations/20260214000000_search_fk_final_entities.js +++ b/plugins/catalog-backend/migrations/20260214000000_search_fk_final_entities.js @@ -71,10 +71,14 @@ async function batchDeleteOrphansMysql(knex, refTable) { * to final_entities(entity_id). This allows search entries to reference * final entities directly, with CASCADE delete when entities are removed. * - * For PostgreSQL and MySQL, the migration is structured to minimize lock - * time on large tables by batch-deleting orphaned rows before any DDL. - * PostgreSQL additionally uses NOT VALID / VALIDATE CONSTRAINT to keep - * the AccessExclusiveLock duration minimal. + * On PostgreSQL, the migration first switches the foreign key to point at + * final_entities using a single ALTER TABLE with a NOT VALID constraint, + * then batch-deletes any pre-existing orphaned rows outside of DDL, and + * finally VALIDATEs the constraint to keep the AccessExclusiveLock window + * as short as possible. + * + * On MySQL, the migration batch-deletes orphaned rows in chunks around the + * foreign key change to reduce lock time on large tables. * * @param {import('knex').Knex} knex */