Jeremy Evans 0663afb335 Add unique indexes and constraints ...

Currently, uniqueness for the following tables is handled by a
unique index in access_tag:

* firewall
* load_balancer
* postgres_resource
* private_subnet
* vm

These tables previously used the unique index in access_tag to
enforce a unique name per project.  When we stop using access_tag
for these, we still need the unique name per project/location
enforced, so this adds a unique index per table to enforce
uniqueness.  Note that load_balancer does not have a location
column, so for load balancer, the unique index is for the
private_subnet_id and name.

This also adds unique indexes for project_id and name for
dns_zone and usage_alert, since they will be needed in the future.

There are 3 additional tables that have project_id and name columns,
but I don't believe they are created by users, so I'm not sure if
a (project_id, name) unique index is appropriate (maybe only unique
name index is appropriate, or something else):

* github_installation
* inference_endpoint
* minio_cluster

I noticed what I think is a bug, in that postgres_resource.name was
unique by itself.  This means that two separate projects/users
cannot create PostgreSQL databases with the same name.  I expect
that was not desired, and stems from when postgres_resource was
originally named postgres_server, so this drops the unique
constraint on name when adding the unique index on (project_id, name).

Additionally, the migration to add the project_id columns did not
make each column a foreign key, so this makes each project_id column
a foreign key referencing project.

2025-01-16 13:29:34 -08:00

1.8 KiB

Raw Permalink Blame History

View Raw