Use sensible names for Indexes, Foreign Keys, Unique Indexes, etc... #8321
Description
Feature Description
Use sensible names for Indexes, Foreign Keys, Unique Indexes, etc...
The Problem
Debugging constraint issues, looking at the database, or looking at stacktraces where constraint's in the database fail, are all made harder than they should be, by having such obfuscated constraint names. Currently we get something like FK_0b82f0b04f37c25a503fb3883cf generated for foreign keys which is less than useful for any human viewing it.
The Solution
By default, many other frameworks add human readable identifiers to these database constraints. Even if you want to keep the unique part for extra safety, adding human readable identifiers clarifies things a lot. For example
Best
FK_user_role_id
Good
FK_user_role_id_0b82f0b04f37c25a503fb3883cf
Bad
FK_0b82f0b04f37c25a503fb3883cf
The same logic should apply to Indexes, references, unique indexes, etc.
Relevant Database Driver(s)
| DB Type | Relevant |
|---|---|
aurora-data-api |
no |
aurora-data-api-pg |
no |
better-sqlite3 |
no |
cockroachdb |
no |
cordova |
no |
expo |
no |
mongodb |
yes |
mysql |
yes |
nativescript |
no |
oracle |
no |
postgres |
yes |
react-native |
no |
sap |
no |
sqlite |
yes |
sqlite-abstract |
no |
sqljs |
yes |
sqlserver |
yes |
Are you willing to resolve this issue by submitting a Pull Request?
- ✖️ Yes, I have the time, and I know how to start.
- ✖️ Yes, I have the time, but I don't know how to start. I would need guidance.
- ✖️ No, I don’t have the time, but I can support (using donations) development.
- ✅ No, I don’t have the time and I’m okay to wait for the community / maintainers to resolve this issue.