catalog-backend: persist location_entity_ref in locations table

Adds a migration that populates a new `location_entity_ref` column on the
`locations` table with the full entity ref of the corresponding
`kind: Location` entity (e.g. `location:default/generated-<sha1hex>`).
Postgres uses an unnest-based batch UPDATE; other engines use a
transaction-wrapped per-row loop.

All code paths in DefaultLocationStore that previously recomputed the hash
from type+target now read `location_entity_ref` directly from the DB row
instead. New rows written by `createLocation` and `#createLocationsByExactUrl`
have the column populated at insert time.

This is step 1 of migrating Location entity names to be based on the stable
row UUID rather than a hash of the mutable target URL.

Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor
This commit is contained in:
Fredrik Adelöw
2026-04-04 20:54:24 +02:00
parent 98d9a75dc2
commit d16311f310
9 changed files with 383 additions and 32 deletions
@@ -0,0 +1,5 @@
---
'@backstage/plugin-catalog-backend': minor
---
Added a `location_entity_ref` column to the `locations` database table that stores the full entity ref of the corresponding `kind: Location` catalog entity for each registered location row. The value is pre-computed and persisted so that it no longer needs to be recomputed from the location's type and target on every read.