I can't find a primary source for this but I believe that for datasets, the IP and port fields are supposed be populated if and only if the dataset kind is "crucible". This comment suggests it:
|
-- Only valid if kind = crucible |
|
ip INET, |
|
port INT4 CHECK (port BETWEEN 0 AND 65535), |
Both this table and the "dataset" table have an explicit constraint to enforce one side of this:
|
CONSTRAINT ip_and_port_set_for_crucible CHECK ( |
|
(kind != 'crucible') OR |
|
(kind = 'crucible' AND ip IS NOT NULL and port IS NOT NULL) |
|
), |
but they allows rows of kind != crucible that have an IP and port set.
If these are unexpected, could we enforce both sides of this in both tables? And also in the model types? I'm hopeful that catch problems like #7299.
I can't find a primary source for this but I believe that for datasets, the IP and port fields are supposed be populated if and only if the dataset kind is "crucible". This comment suggests it:
omicron/schema/crdb/dbinit.sql
Lines 3769 to 3771 in c140817
Both this table and the "dataset" table have an explicit constraint to enforce one side of this:
omicron/schema/crdb/dbinit.sql
Lines 595 to 598 in c140817
but they allows rows of kind !=
cruciblethat have an IP and port set.If these are unexpected, could we enforce both sides of this in both tables? And also in the model types? I'm hopeful that catch problems like #7299.