Building on #23 and #24, we need support for foreign key constraints. I think that "from" is more clear to new users than "foreign". So I think we should support a from() function with a "table.column" as the one argument. This will require:
modifying create_schema() to add a foreign key constraint for the main table (not the _constraint table)
determining the right order to load the tables so that foreign key constraints can be satisfied; check for cycles and fail with a clear error message; then actually load the tables in the right order
actually checking the foreign key constrain somewhere under validate_rows()
Note: In the future I can see the need to specify more than one column: from(import.label, index.label). I think this would not just translate into a foreign key constraint in SQL -- it would require an additional view that gets the union of the two columns. I don't want to worry about this yet.
jamesaoverton
commented
2 years ago
Building on #23 and #24, we need support for foreign key constraints. I think that "from" is more clear to new users than "foreign". So I think we should support a
from()function with a "table.column" as the one argument. This will require:create_schema()to add a foreign key constraint for the main table (not the _constraint table)validate_rows()Note: In the future I can see the need to specify more than one column:
from(import.label, index.label). I think this would not just translate into a foreign key constraint in SQL -- it would require an additional view that gets the union of the two columns. I don't want to worry about this yet.