[Feature Request] One way relations without overhead
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 12/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- database
Research direction
This is a design proposal for ZenStack's schema language, not a scoped task: it asks that a relation be recognized implicitly and its back-relation fields omitted from the generated model, with the alternative of an explicit @relation(oneWay: true) attribute. Start by reading the Prisma-schema parsing and relation-resolution code paths in the ZenStack repo to see where back-relations are currently required, and review the referenced prisma/prisma#2018 thread for the long-standing constraints. Nothing is named in the issue itself, no test or file is pointed at, and the many-to-many case is explicitly left open, so scope has to be settled before any implementation begins.
Written by the indexing model from the issue text.
Description
Problem
In many cases a user may want to create a one-way relationship between models, for example:
model User {
id Int @id
image Image?
}
model Product {
slug String @id
image Image?
}
model Post {
id Int @id
images Image[]
}
model Image {
id String @id
path String
userId Int? @unique
user User? @relation(fields: [userId], references: [id])
productSlug String? @unique
product Product? @relation(fields: [productSlug], references: [slug])
postId Int?
post Post? @relation(fields: [postId], references: [id])
}
The image model is over-specified and causes not only headaches when designing models, but also later when referencing the data.
This issue has been a known limitation of Prisma for over 7 years and has over 100 comments as seen in #2018.
Proposed solution
Best solution would be to implicitly recognise relations, and if the user does not explicitly define a back-relation, then ZenStack should omit relation fields in the underlying model. This way, model from before would look like this:
model User {
id Int @id
image Image?
}
model Product {
slug String @id
image Image?
}
model Post {
id Int @id
images Image[]
}
model Image {
id String @id
path String
}
Thus, when referencing User we have access to Image, but when referencing Image we do not necessarily have references to User/Product/Post.
I do not see any side effects with this solution and it should not introduce any breaking changes. If some were to come up during development, ZenStack could implement some attribute, like @relation(oneWay: true) to make sure the user knows what they're doing and explicitly configure the model with one way relation.
Alternatives
There really aren't any good alternatives, as seen in Prisma issue referenced earlier, the best solution are janky TypeScript types like Omit or as any all over the place, which introduce bugs and break with every change to the model. These also does not remove the problem of very long model definitions.
Additional considerations
It would also be great if it were possible to define explicit many-to-many relations one way. As far as I'm aware, my solution would be a drop-in replacement and should work out-of-the-box, but this may need to be additionally though through.
- Dominant language
- TypeScript
- Stars
- 2.9k
- Forks
- 157
- Avg merge
- 11h 42m
- Merged PRs (30d)
- 20
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from zenstackhq/zenstack
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
zenstackhq/zenstack#2873 ·
Maintainers usually reply within 1 day
-
runtime
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
zenstackhq/zenstack#2868 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
zenstackhq/zenstack#2694 · 3 comments ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
zenstackhq/zenstack#2659 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
zenstackhq/zenstack#2542 · 1 comment ·
Maintainers usually reply within 1 day
All issues in zenstackhq/zenstack
Similar issues
-
chore v2
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
modelcontextprotocol/servers#5115 ·
Maintainers usually reply within 1 day
-
beginner bug good first issue
Difficulty 1/5 Under an hour Newbie friendliness 85/100
philaconvalley/website#168 ·
Maintainers usually reply within 1 day
-
bug frontend good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
oss-slu/lrda_mobile#294 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
hatchet-dev/hatchet#5179 ·
Maintainers usually reply within 1 day