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
The current schedule table allows duplicates in the name field. However, if a new table wants to reference the name of the schedule table as a foreign key, it will fail to do so because the "name" is not unique or a primary key.
The following is one example: in this PR, the author want to reference name in support_schedules as the foreign key in support_occupant_physical_characteristics table.
Thank you for the comment. I will follow Weili's suggestion at this stage. Originally, the `support_occupant_physical_characteristics` has the following code, which sets `name` in `support_schedules` as the foreign keys. However, this setting cannot pass the test because `name` is not a unique value. Do you have any suggestions to do this right?
The current schedule table allows duplicates in the
name
field. However, if a new table wants to reference thename
of the schedule table as a foreign key, it will fail to do so because the "name" is not unique or a primary key.The following is one example: in this PR, the author want to reference
name
insupport_schedules
as the foreign key insupport_occupant_physical_characteristics
table.Originally posted by @jiangyilin123 in #97 (comment)
The text was updated successfully, but these errors were encountered: