Current Behavior

We make use of auto-generated CHECK constraints for enum values. For example, for Project#classifier:

Unfortunately, the CHECK constraint is only generated when the schema is initially created, but then never updated again as new values are added to the respective enum. As reported via Slack:

[...] we've noticed a discrepancy in the database constraint COMPONENT_CLASSIFIER_check across the instances (all of them using PostgreSQL). In particular, one instance includes DEVICE_DRIVER as an allowed value, while another instance does not. While it's possible to manually adjust this, shouldn't this be handled automatically by the database migrations?

The correct way to update a constraint is to drop and re-create it. DataNucleus does not do this, so it has to be a manual change performed by us.

Unfortunately, DataNucleus does not provide a means to specify a name for the generated CHECK constraint, which makes addressing it tricky. While in PostgreSQL the generated name is still predictable (see quote above), it is not for MSSQL:

In such cases, we need to discover the correct constraint somehow.

Steps to Reproduce

N/A

Expected Behavior

Identity existing constraints affected by this issue. Drop and re-create them as part of a dedicated migration.

Dependency-Track Version

4.13.0-SNAPSHOT

Dependency-Track Distribution

Container Image, Executable WAR

Database Server

N/A

Database Server Version

No response

Browser

N/A

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported