Use better column names in join table for implicit m-n relations
## Problem I have the following schema which includes an implicit many-to-many relation: ```prisma model Permission { id Int @id @default(autoincrement()) name String users User[] } model User { id Int @id @default(autoincrement()) userName String @unique hashedPassword String permissions Permission[] } ``` Prisma creates a join table with columns called `A` and `B`. When I inspect this database in some database tool, it is not clear which column represents which table in this relation. ## Suggested solution Prisma should use a combination of a table name and an ID column name when naming columns of the join table. In this case, these columns would be called `permission_id` and `user_id`. ## Alternatives Or Prisma could allow us to specify column names in `@relation` attribute: ```prisma model Permission { id Int @id @default(autoincrement()) name String users User[] @relation(map: ["permission_id"]) } model User { id Int @id @default(autoincrement()) userName String @unique hashedPassword String permissions Permission[] @relation(map: ["user_id"]) } ``` ## Additional context I use Prisma 3.4.1 with SQLite database. Related issues: * https://github.com/prisma/prisma/issues/3381 * https://github.com/prisma/prisma/issues/5234 * https://github.com/prisma/prisma/issues/5369
Posted by livthomas on Nov 13, 2021, 3:55 PM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
Use better column names in join table for implicit m-n relations
## Problem I have the following schema which includes an implicit many-to-many relation: ```prisma model Permission { id Int @id @default(autoincrement()) name String users User[] } model User { id Int @id @default(autoincrement()) userName String @unique hashedPassword String permissions Permission[] } ``` Prisma creates a join table with columns called `A` and `B`. When I inspect this database in some database tool, it is not clear which column represents which table in this relation. ## Suggested solution Prisma should use a combination of a table name and an ID column name when naming columns of the join table. In this case, these columns would be called `permission_id` and `user_id`. ## Alternatives Or Prisma could allow us to specify column names in `@relation` attribute: ```prisma model Permission { id Int @id @default(autoincrement()) name String users User[] @relation(map: ["permission_id"]) } model User { id Int @id @default(autoincrement()) userName String @unique hashedPassword String permissions Permission[] @relation(map: ["user_id"]) } ``` ## Additional context I use Prisma 3.4.1 with SQLite database. Related issues: * https://github.com/prisma/prisma/issues/3381 * https://github.com/prisma/prisma/issues/5234 * https://github.com/prisma/prisma/issues/5369
Comments (0)
No comments yet. Start the discussion.