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
We currently lack any sort of automated referential data integrity validation. This means that stale data may accumulate in tables if entities are not deleted properly. This also means that it is possible for data errors to go unnoticed, resulting in bugs which are difficult to track down.
It would be good to set up foreign key constraints for each of our relations. Doing so is not necessarily straightforward however. We currently have a number of places where data is not deleted appropriately and it is possible for entities to violate a new constraint. In these instances, the most practical option is probably to just delete the row which doesn't meet the constraint.
The text was updated successfully, but these errors were encountered:
Our database schema is currently a mess. With no foreign keys defined,
it is easy to accidentally forget to update a relationship field
properly when an entity is created or deleted. Virtually all modern
relational databases support foreign key constraints, and there is no
reason for us to not add them.
In a first step towards #1442, this PR adds foreign key constraints to
all of the table columns which reference a project's ID. This should be
a relatively low risk operation for production systems, but it creates a
bit of a headache when writing tests, because creating any model which
references a project necessarily requires a project model to be created
as well.
This PR builds upon the work in #1655, and adds foreign key constraints
to all buildid columns. Like #1655, a handful of changes to our test
suite were required to ensure that the constraints were fully met during
the testing process.
This is related to issue #1442.
We currently lack any sort of automated referential data integrity validation. This means that stale data may accumulate in tables if entities are not deleted properly. This also means that it is possible for data errors to go unnoticed, resulting in bugs which are difficult to track down.
It would be good to set up foreign key constraints for each of our relations. Doing so is not necessarily straightforward however. We currently have a number of places where data is not deleted appropriately and it is possible for entities to violate a new constraint. In these instances, the most practical option is probably to just delete the row which doesn't meet the constraint.
The text was updated successfully, but these errors were encountered: