Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature Request] One way relations without overhead

Open
#2,681 1 comment 3 reactions 0 assignees View on GitHub

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from zenstackhq/zenstack

All issues in zenstackhq/zenstack

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.