mirror of
https://github.com/sqlitebrowser/sqlitebrowser.git
synced 2026-01-17 01:09:36 -06:00
43107ea773
This is a long overdue continuation of some previous refactoring effort. Before this we used to store the columns a table constraint belongs to within the constraint object itself. So for example, a foreign key constraint object would store the referencing as well as the referenced column names. While initially simple, this approach has the downside of duplicating certain data, thus breaking ownership and complicating matters later on. This becomes obvious when renaming the referencing column. The column name clearly is a feature of the table but in the previous approach it also needs to be changed in the foreign key object as well as in any other constraint for this field even though the constraint itself has not been touched. This illustrates how a constraint is not only a property of a table but the field names (a property of the table) are also a property of the constraint, creating a circular ownership. This makes the code hard to maintain. It also invalidates references to constraints in the program needlessly, e.g. when only changing a column name. With this commit the column names are removed from the constraint types. Instead they are now solely a property of the table. This, however, raised another issue. For unique constraints and primary keys it is possible to use expressions and/or sorted keys whereas for foreign keys this is not possible. Additionally check constraints have no columns at all. So when not storing the used columns inside the constraint objects we need to have different storage types for each of them. So in a second step this commit moves the code from a single data structure for storing all table constraints to three data structures, one for PK and unique, one for foreign keys, and one for check constraints. By doing all this, this commit also changes the interface for handling quite a bit. The new interface tends to use more explicit types which makes the usage code easier to read. Please note that this is still far from finished. But future development on this should be a lot easier now.