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:
@@ -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.
|
||||
Reference in New Issue
Block a user