Currently we have a status table, which holds the following entries we ingest by default:
| id |
slug |
name |
description |
| 85b912db-fc1b-4e75-8b27-68b68c0ed828 |
affected |
Affected |
Vulnerabililty affects |
| 619aba21-abba-4220-9e3e-110cf87e5393 |
not_affected |
Not Affected |
Vulnerabililty does not affect |
| c0273e43-2b0c-4dae-a3b3-c4f9733fbfa7 |
fixed |
Fixed |
Vulnerabililty is fixed |
| 23613500-86a4-4cdb-bc92-8c74e18764da |
under_investigation |
Under Investigation |
Vulnerabililty is under investigation |
| 2bb0325b-0948-44ea-bab7-46af9fc834eb |
fixed |
Fixed |
Vulnerabililty is fixed |
| 858a3f17-d864-4be8-932e-4a634de47b8b |
recommended |
Recommended |
Vulnerabililty is fixed & recommended |
The purl_status table then has a field of status_id, referencing an entry there. Which always requires a JOIN.
I would propose to just use a custom type, e.g. enum and only store the slug. Having all other variations (if required) in code.
Currently we have a
statustable, which holds the following entries we ingest by default:The
purl_statustable then has a field ofstatus_id, referencing an entry there. Which always requires aJOIN.I would propose to just use a custom type, e.g. enum and only store the
slug. Having all other variations (if required) in code.