You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While testing the design of some schemas, I noticed that any Foreign Keys get saved without UPDATE/DELETE CASCADE specifications. That's probably fine in most cases, but there are situations where having that can be useful.
Is that something that is supported but not documented? Or perhaps it's something that is beyond the scope of this package?
Example:
- name: Names"@id": "#Names"description: "Additional identifiers for objects in Sources table"primaryKey:
- "#Names.id"
- "#Names.name"columns:
- name: id"@id": "#Names.id"datatype: longdescription: Main identifier for an object; links to Sources tablenullable: false
- name: name"@id": "#Names.name"datatype: stringlength: 100description: Identifier for sourcenullable: falseconstraints:
- name: Names_id_Sources_id"@type": "ForeignKey""@id": "#FK_Names_id_Source_id"description: Link Names to Sources tablecolumns:
- "#Names.id"referencedColumns:
- "#Sources.id"
produces Postgres sql of the form:
CREATETABLEexomast."Names" (
id BIGINTNOT NULL,
name VARCHAR(100) NOT NULL,
PRIMARY KEY (id, name),
CONSTRAINT"Names_id_Sources_id"FOREIGN KEY(id) REFERENCES exomast."Sources" (id)
)
;
COMMENT ON TABLE exomast."Names" IS 'Additional identifiers for objects in Sources table';
COMMENT ON COLUMN exomast."Names".id IS 'Main identfier for an object; links to Sources table';
COMMENT ON COLUMN exomast."Names".name IS 'Identifier for source';
COMMENT ON CONSTRAINT "Names_id_Sources_id" ON exomast."Names" IS 'Link Names to Sources table';
But I would have wanted the foreign key to be something like:
CONSTRAINT"Names_id_Sources_id"FOREIGN KEY(id) REFERENCES exomast."Sources" (id) ON DELETE CASCADE
so that if I delete the entry from Sources all of its references in Names are deleted.
The text was updated successfully, but these errors were encountered:
While testing the design of some schemas, I noticed that any Foreign Keys get saved without UPDATE/DELETE CASCADE specifications. That's probably fine in most cases, but there are situations where having that can be useful.
Is that something that is supported but not documented? Or perhaps it's something that is beyond the scope of this package?
Example:
produces Postgres sql of the form:
But I would have wanted the foreign key to be something like:
so that if I delete the entry from Sources all of its references in Names are deleted.
The text was updated successfully, but these errors were encountered: