| 1 | -- Which pull requests carry which labels. |
| 2 | -- |
| 3 | -- **A second join table rather than one polymorphic one.** A |
| 4 | -- `labelled (kind, subject_id, label_id)` table would hold both in one place and read |
| 5 | -- tidily, and it would have to give up the two `on delete cascade`s that make this |
| 6 | -- correct: SQLite cannot point a foreign key at whichever table a `kind` column names, |
| 7 | -- so deleting a pull request would leave its label rows behind for the application to |
| 8 | -- sweep by hand. The same argument at the type level is why `IssueId` and |
| 9 | -- `PullRequestId` are different types. The cost is a parallel set of port methods, |
| 10 | -- which is mechanical; the cost of the other shape is integrity, which is not. |
| 11 | -- |
| 12 | -- Labels themselves are shared: this table and `issue_labels` both reference `labels`, |
| 13 | -- so `bug` means one thing on a repository whichever kind of thing wears it, and there |
| 14 | -- is one page to manage them on. |
| 15 | ( |
| 16 | pull_request_id text not null references pull_requests (id) on delete cascade, |
| 17 | label_id text not null references labels (id) on delete cascade, |
| 18 | primary key (pull_request_id, label_id) |
| 19 | ); |
| 20 | |
| 21 | -- The other direction, exactly as `issue_labels_label`: filtering the list to a label, |
| 22 | -- and counting how many requests each label is on. |
| 23 | (label_id, pull_request_id); |