Support for splitting Prisma schema into multiple files

[albertoperdomo]

Problem

Prisma currently only supports one single Prisma Schema file. Developers want more flexibility for managing their Prisma Schema files.

Motivations:

• breaking up large schema files to make them more manageable
• flexible integration with certain architectures, i.e. each module has its own self-contained logic including its schema

Solution

Support importing additional schema files, i.e. import "user.schema", import models/*.prisma or import modules/**/*.prisma.

Alternatives

Not researched at this time.

Additional context

#92

[ChristophDietrich]

Like prisma one ... there was a feature like this implemented.

[paniavula]

Appreciate prioritisation of this. It is really painful to write all the schema in one file.

[beeplin]

badly need this feature. currently I have to cat a.prisma b.prisma > schema.prisma. it works but is so clumsy.

[JontyCoertzen]

Any update on this?

[SteveSonoa]

Any movement on this? Really looking for this solution.

[yhaiovyi]

It's a dealbreaker for me...

[cudba]

until this is part of the prisma cli, we extracted a small script which we use internally into this tiny cli prisma-merge. its nothing fancy but works for us currently. feel free to use it or copy the source and tailor it to your needs.

[hgezim]

Ideally, I'd like my models to live near their/in modules in Nest.

[slinden2]

Would be a nice feature. A single file is not maintainable.

[kevinvdburgt]

Please, don't be hostile.

I would love to see this feature as well coming to Prisma 2. There is a workaround (we used in some projects) which might help:

cat *.part.prisma > schema.prisma
yarn prisma generate

[yazer79]

I think this is a "basic" feature for any project. Many months passed now, and there is no update on this.
I can't believe Iit is so hard to make a modular schema file and that would actually take almost a year and no progress on this basic matter

[paulosalvatore]

I agree that this is really needed, but npx prisma-merge provides a great workaround.

Thank you guys and looking forward on this implementation :)

[ncirkel]

Good workarounds exist and have been proposed, but one basic modular use case that is holding me back is this one:

Module A:

type Story {
  id: ID!
}

Module B:

type Product {
  id: ID!
  relatedStories: [Story!]!
}

extend type Story {
  relatedProducts: [Product!]!
}

This wasn't possible in Prisma 1 either, but it would be amazing if the Prisma devs could make that happen.

[ChristophDietrich]

Good workarounds exist and have been proposed, but one basic modular use case that is holding me back is this one:

Module A:

type Story {

  id: ID!

}

Module B:

type Product {

  id: ID!

  relatedStories: [Story!]!

}



extend type Story {

  relatedProducts: [Product!]!

}

This wasn't possible in Prisma 1 either, but it would be amazing if the Prisma devs could make that happen.

This would be very very awesome 👏 👏👏

[KingProphecyhk]

Dude this feature is a must for better maintanance of code! Dev team please take a look on it.

[akirarika]

This feature is indeed much needed, but I think there will be many challenges in implementing it.

However, it seems that implementing this feature is not difficult. You just need to merge all the files into one "schema.prisma" file before the generation phase.

Nevertheless, I have thought of some issues, mainly regarding the Prisma VSCode extension. I guess the biggest challenge lies in handling the relational relationships. Although it may seem simple to merge the files together, it would be difficult for the Prisma VSCode extension to maintain its existing functionality, such as code fixes for relational table relationships.

The Prisma team has not yet planned to implement this feature, and I suspect it may be related to these challenges.

If my assumption is correct, I do have a good idea (although I'm not sure if it's feasible). We can work on the VSCode extension layer. I recall that the Vue extension "Volar" has a feature that can split a .vue file into <style>, <template>, and <script> sections, displaying them simultaneously in the window. Perhaps Prisma can do something similar.

(That means displaying only a portion of the file in the editor, not the entire file.)

We can define a comment syntax to mark a code block as a namespace:

// namespace-start: YourNamespace

model User {
  ...
}

// namespace-end: YourNamespace

When opening the "schema.prisma" file, if there are multiple namespaces in the code and the number of namespaces is greater than or equal to two, we can default to displaying only the code within the namespace closest to the top of the file in the editor area. We can provide functionality in the bottom-right corner of VSCode to select which namespace's code to display or create a new namespace.

I believe this could be a relatively low-cost solution, but I'm not sure how difficult it would be to implement.

[akirarika]

English is not my native language, so my description may be a bit confusing

[akirarika]

I already have nearly a hundred tables, and I find myself constantly navigating between them...

[julienfdev]

Nevertheless, I have thought of some issues, mainly regarding the Prisma VSCode extension. I guess the biggest challenge lies in handling the relational relationships. Although it may seem simple to merge the files together, it would be difficult for the Prisma VSCode extension to maintain its existing functionality, such as code fixes for relational table relationships.

VSCode TSL handles tens of thousands of relationships over thousands of files with relatively good performance, I think Prisma can handle autocomplete spanning a dozen of files...

[ajmnz]

@akirarika You might find useful prisma-import for VSCode support on splitting your schema. Not the ideal solution, but should get you going while this is not implemented natively.

[akirarika]

@ajmnz I saw your work! That's great! I've decided to stop tinkering and use prisma-import

I think this might be the best solution so far, I've given you a star for it!

[2314-RAustin]

I work with DDD and Nest, the modularization of a project is very important in large projects.
I wanted to use prism to learn more but I reached a point where it is an impediment to using it.

I hope 2024 is the year it arrives

[Bowis]

So this is just never going to come out? Yet, prisma focuses on things like... DATABASE CACHING, because that is THE thing that people are asking for. Not the 298 comments here asking for a core part of their product to be updated, what an absolute joke.

[mordechaim]

The entitlement in this thread is surreal...

Exactly how much did you pay to use Prisma?
How many commits did you contribute to this open source project?

How about creating a pull request instead of complaining?

I'm not affiliated with Prisma, just an observer from the side.

[CamilleHbp]

The entitlement in this thread is surreal...

Exactly how much did you pay to use Prisma? How many commits did you contribute to this open source project?

How about creating a pull request instead of complaining?

I'm not affiliated with Prisma, just an observer from the side.

I'd rather have people voicing their disapproval. That's what allows things to evolve. The people being “content” never made things change. Yes, some people voice their disagreement too strongly, but I take it as them being passionate about Prisma. And ultimately disappointed when it fails a bit short on some of their expectations. Criticising is a proof that you care about something. And that's a lot better (to me) than never saying anything.

And no, you should not have to create a PR to voice that something should exist. At least the Prisma team knows that the feature is requested by some people. That doesn't mean they have to do it. I continue to use the project, but I am happy that this issue exists and that it is still alive, as I really miss this feature and think it is essential for big projects.

[daniellwdb]

The entitlement in this thread is surreal...
Exactly how much did you pay to use Prisma? How many commits did you contribute to this open source project?
How about creating a pull request instead of complaining?
I'm not affiliated with Prisma, just an observer from the side.

I'd rather have people voicing their disapproval. That's what allows things to evolve. The people being “content” never made things change. Yes, some people voice their disagreement too strongly, but I take it as them being passionate about Prisma. And ultimately disappointed when it fails a bit short on some of their expectations. Criticising is a proof that you care about something. And that's a lot better (to me) than never saying anything.

And no, you should not have to create a PR to voice that something should exist. At least the Prisma team knows that the feature is requested by some people. That doesn't mean they have to do it. I continue to use the project, but I am happy that this issue exists and that it is still alive, as I really miss this feature and think it is essential for big projects.

The amount of "fix this" comments don't change the pace at which things are implemented. They (used to) look at the amount of upvotes on issues(?) to prioritise. It's really annoying when you try to follow this thread in case the status is ever updated so please quit it. Any attempt to implement this could have been a PR since they don't seem to have shown any sign of going in a specific direction. Maybe that way there would be some activity in the PR itself. You can just use any of those implementations until an official one is ready.

[CamilleHbp]

The entitlement in this thread is surreal...
Exactly how much did you pay to use Prisma? How many commits did you contribute to this open source project?
How about creating a pull request instead of complaining?
I'm not affiliated with Prisma, just an observer from the side.

I'd rather have people voicing their disapproval. That's what allows things to evolve. The people being “content” never made things change. Yes, some people voice their disagreement too strongly, but I take it as them being passionate about Prisma. And ultimately disappointed when it fails a bit short on some of their expectations. Criticising is a proof that you care about something. And that's a lot better (to me) than never saying anything.
And no, you should not have to create a PR to voice that something should exist. At least the Prisma team knows that the feature is requested by some people. That doesn't mean they have to do it. I continue to use the project, but I am happy that this issue exists and that it is still alive, as I really miss this feature and think it is essential for big projects.

The amount of "fix this" comments don't change the pace at which things are implemented. They (used to) look at the amount of upvotes on issues(?) to prioritise. It's really annoying when you try to follow this thread in case the status is ever updated so please quit it. Any attempt to implement this could have been a PR since they don't seem to have shown any sign of going in a specific direction. Maybe that way there would be some activity in the PR itself. You can just use any of those implementations until an official one is ready.

Yes, you are quite right and make good points. I was more reacting to calling people complaining about a lack of feature as if it were “entitlement”.

I did upvote the thread since I had not much to bring to the discussion. I will never have time to implement this feature, as I have too many other projects that I'd rather spend time on. ^^ Meanwhile, I'm using prisma-import. It would be nice to have a native way to do it instead of using external tooling, though.

I've myself unsubscribed to the thread since there is no progress and all I get is people adding to the noise. :D You can't really prevent that, though, so I'd rather check manually.

[shvamabps]

The entitlement in this thread is surreal...
Exactly how much did you pay to use Prisma? How many commits did you contribute to this open source project?
How about creating a pull request instead of complaining?
I'm not affiliated with Prisma, just an observer from the side.

I'd rather have people voicing their disapproval. That's what allows things to evolve. The people being “content” never made things change. Yes, some people voice their disagreement too strongly, but I take it as them being passionate about Prisma. And ultimately disappointed when it fails a bit short on some of their expectations. Criticising is a proof that you care about something. And that's a lot better (to me) than never saying anything.
And no, you should not have to create a PR to voice that something should exist. At least the Prisma team knows that the feature is requested by some people. That doesn't mean they have to do it. I continue to use the project, but I am happy that this issue exists and that it is still alive, as I really miss this feature and think it is essential for big projects.

The amount of "fix this" comments don't change the pace at which things are implemented. They (used to) look at the amount of upvotes on issues(?) to prioritise. It's really annoying when you try to follow this thread in case the status is ever updated so please quit it. Any attempt to implement this could have been a PR since they don't seem to have shown any sign of going in a specific direction. Maybe that way there would be some activity in the PR itself. You can just use any of those implementations until an official one is ready.

Yes, you are quite right and make good points. I was more reacting to calling people complaining about a lack of feature as if it were “entitlement”.

I did upvote the thread since I had not much to bring to the discussion. I will never have time to implement this feature, as I have too many other projects that I'd rather spend time on. ^^ Meanwhile, I'm using prisma-import. It would be nice to have a native way to do it instead of using external tooling, though.

I've myself unsubscribed to the thread since there is no progress and all I get is people adding to the noise. :D You can't really prevent that, though, so I'd rather check manually.

• Is using an external tool for a certain feature a safe option?
• If a certain type of feature is present in the product itself, then is it sensible to use something that is created using the deficiency of that product?

[ronaldroe]

The entitlement in this thread is surreal...
Exactly how much did you pay to use Prisma? How many commits did you contribute to this open source project?
How about creating a pull request instead of complaining?
I'm not affiliated with Prisma, just an observer from the side.

I'd rather have people voicing their disapproval. That's what allows things to evolve. The people being “content” never made things change. Yes, some people voice their disagreement too strongly, but I take it as them being passionate about Prisma. And ultimately disappointed when it fails a bit short on some of their expectations. Criticising is a proof that you care about something. And that's a lot better (to me) than never saying anything.
And no, you should not have to create a PR to voice that something should exist. At least the Prisma team knows that the feature is requested by some people. That doesn't mean they have to do it. I continue to use the project, but I am happy that this issue exists and that it is still alive, as I really miss this feature and think it is essential for big projects.

The amount of "fix this" comments don't change the pace at which things are implemented. They (used to) look at the amount of upvotes on issues(?) to prioritise. It's really annoying when you try to follow this thread in case the status is ever updated so please quit it. Any attempt to implement this could have been a PR since they don't seem to have shown any sign of going in a specific direction. Maybe that way there would be some activity in the PR itself. You can just use any of those implementations until an official one is ready.

Yes, you are quite right and make good points. I was more reacting to calling people complaining about a lack of feature as if it were “entitlement”.
I did upvote the thread since I had not much to bring to the discussion. I will never have time to implement this feature, as I have too many other projects that I'd rather spend time on. ^^ Meanwhile, I'm using prisma-import. It would be nice to have a native way to do it instead of using external tooling, though.
I've myself unsubscribed to the thread since there is no progress and all I get is people adding to the noise. :D You can't really prevent that, though, so I'd rather check manually.

• Is using an external tool for a certain feature a safe option?
• If a certain type of feature is present in the product itself, then is it sensible to use something that is created using the deficiency of that product?

If a presumably ubiquitous feature is missing from the library after 3.5 years, despite a massive number of users behind it, you have to just assume the maintainers don't care. Yep, it's an open source project, and they're working it for free. We get it. But, when you have to use a 3rd party solution for something that is standard everywhere else (and let me point out that "everywhere else" isn't an exaggeration in this context), you have to wonder about the status of the project in general. Does that mean we get to come at the people who maintain it? No. Does that mean we can ask them why they've either abandoned the project or decided they don't care about feedback? Yes, we absolutely can and should.

[LuanComputacao]

I agree with @ronaldroe.

💩 alert
There are some options:

1. They don't have idea about how to implement/fix it
2. They just don't care about it (reports or enhancements)
3. The real intention about prisma It's just to small projects
4. Many reasons that no one knows

[akirarika]

I have finished writing the code! I spent the whole day learning how to develop a VSCode extension.

https://github.com/akirarika/prisma-outline

I have implemented the VSCode extension I mentioned earlier. Comments starting with // * will now be recognized as an outline, without the need for an ending symbol, unlike the previous idea.

The advantage of this approach is that it is fully compatible with the official Prisma extension, and there is no need to worry about additional refactoring costs in the future if Prisma provides similar functionality as first-party support, and you can always use the latest version of the Prisma VSCode extension.

However, the downside is quite obvious. The user experience is still not as good as the file splitting approach. If you are looking for an implementation similar to file splitting, I believe prisma-import is the least invasive and provides the best user experience solution.

[BenjaVR]

I am following this thread to keep up to date with any official developments in this area. There are already many community workarounds at this point.

It's a bit annoying to get notifications all the time. @janpio maybe this issue can be limited/locked? Reactions are the way to show support for issues anyway.

[shvamabps]

The thing is it is always a good thing that instead of using a third party package for something that can be implemented in the base package.

[mohdashiqtp]

There is a library called multiple-schemas will it work ?

[jonathan-messina]

Four years and still nothing?

[gitcodebob]

Medium mentions: https://medium.com/@joydip007x/how-to-use-multiple-schema-in-prisma-40cc6b6f8d9c
Repo: https://github.com/joydip007x/Prisma-MultiSchema

[shayan0v0n]

I guess we hardly need this feature :)

[beeman]

I guess we hardly need this feature :)

Indeed. Just use something like ZenStack if you want some extras that Prisma doesn't have the bandwidth or interest for.

[shayan0v0n]

I guess we hardly need this feature :)

Indeed. Just use something like ZenStack if you want some extras that Prisma doesn't have the bandwidth or interest for.

Exactly, thanks :)

[arshamhusen]

Any updates on this?

Need this feature ASAP.

[shahinghasemi]

It's pretty big step towards schema maintainability. This way we can split the schema files based on some logic then prisma should be able to merge them all together and process the single generated schema file.

I need it crucially.

[yamada-wacul]

When a schema grows large, it is a very natural request to split it into multiple files.
ZenStack is too huge, and the forced use of VSCode is also too big a solution for writing ORM schemas. I would like to mention again that this issue continues to be alive and well.

And the personal opinion that "it's not necessary for me" is a form of spam that does nothing to advance the issue.