try setting the schema path to: "schema": "src"

I was able to make it work with

"prisma": {
  "schema": "./server"
}

https://www.prisma.io/docs/orm/prisma-schema/overview/location

I will be curious to know, aside from syntax preferences, are there any usecases that current preview feature does not solve for you?

@nlynzaad Thank you for the detailed explanation! I can't get it to work though. Using the following folder structure:

@bowis from your screenshot you shouldn't need any "empty" files or any special config other than enabling the preview feature.

I've adjusted the previously linked repository, under a new branch reproduction, with a bare reproduction of what you have shown here, and it just works. Look at it and compare cause somewhere you are missing something small.

Ensure you have enabled the prismaSchemaFolder preview feature, your package.json is pointing to the correct schema location (in your case it doesn't look like you need to set anything here so if you did try removing that), and that your relations are mapped correctly, also double check your extension is updated. These might sound stupid but honestly, it's the only things I can think of without some small reproduction in stackblitz or something similar to look at.

@nlynzaad thanks again! I'm so confused now, seems like I replicated the whole structure even though im still getting the errors. Plugin is 5.21.1. Thought the types generator could mess with it, but even when removing that i get the errors.

@bowis I recreated what you have given here as a new commit to the branch mentioned earlier and I still can't replicate the problem. You can see what I did there.

my best guess is that you have an issue with the extension or its settings, VSCode settings/caching or your dev environment (for example things like flatpaks/snaps can make things a bit more difficult if you are in a Linux environment, as it is containerized).

Maybe try removing the extension and reinstalling it again (close and reopen VSCODE after uninstalling), clean install of VSCode or try another editor completely like WebStorm (non-commercial license is free now), with the prisma extension installed, to see if you can replicate it.

Another good option is to try and recreate a minimal reproduction of what you have on codesandbox or similar online IDEs, this should almost guarantee you a clean slate on all of the above. Also maybe clone the repo and the branch and see if the problem persists with this "working" version.

Unfortunately, it doesn't seem like something I would be able to assist with. but this should help you to at least start getting an idea of where the issue might be.

@janpio This issue appears to persist in Prisma versions 7.3.0 and 31.4.0.
While the empty-file workaround is effective, I’m wondering if a more robust approach is possible.
Since the 'schema' option in prisma.config.ts is now the default and recommended way to define the schema directory in Prisma v7+, could the extension traverse the directory tree until it finds the configuration file and use that path to find all .prisma files?
Furthermore, since prisma.config.ts can only be placed under the project root, could we locate all the package.json files and check if there is a Prisma configuration file in the same directory to find all the .prisma files?

Did this fix it for you?
Did you first keep an empty prisma/schema.prisma file, while also having prisma/schema/*.prisma?

Yes, right now if both schema.prisma and prisma/schema exist only first one will be used, next version will have more explicit and helpful error.

@janpio

Did this fix it for you?

Yes I did!!

Did you first keep an empty prisma/schema.prisma file, while also having prisma/schema/*.prisma?

No!
I use only one schema.prisma file in prisma directory not subdirectory like ths!!

├── schema
│   ├── gender.prisma
│   └── user.prisma
├── schema.prisma

and then this error hppend!

so I thisk to use this freature and then split file, we have to put file into subdirecory like this!!

├── schema
│   └── schema.prisma
│   ├── gender.prisma
│   └── user.prisma

@SevInf

Yes, right now if both schema.prisma and prisma/schema exist only first one will be used, next version will have more explicit and helpful error.

thank you🥰 I love your idea and if i find the message, the message will helup us!!

In case someone needs it: the schema path must be referenced to the directory and not to the .prisma file in order to work. (for example: src/prisma/schema and not src/prisma/schema/schema.prisma)

You could put your canonical dev.prisma in some other location and then copy or symlink it into prisma/schema in and out depending on the environment.

That's good method.
But, I prefer supports environment variable.

Anyway, thank you for the solution.

Point to the directory, not individual files within it:

npx prisma migrate diff \
--from-empty \
--to-schema-datamodel prisma/schema \
--script > prisma/migrations/0_init/migration.sql

Could you post the contents of your main.prisma though, for us to verify the issue?

Hey was able to point to the folder to get it working. Thanks for your help.

me too! Now I can squash my migrations!! please update the squashing migrations part of the docs with this.

I think you can achieve what you want today by symlinking domain1 and domain2 directories into specific-to-app1 and specific-to-app2 directories. Let us know if that works for you!

@SevInf This (kinda) works. I feel like it's not ideal as now the symlinks show up in each "app"'s directory structure making it visually unclear that they're shared models and not specific to that app.

However, more importantly, an issue arose is that the shared models are not finding references to other shared models.

I mimicked the directory structure of my monorepo (Nx) under the Prisma directory.

prisma/
├─ apps/
│  ├─ app1/
│  │  ├─ migrations/
│  │  ├─ schema/
│  │  │  ├─ org            // (symlink)
│  │  │  ├─ person         // (symlink)
│  │  │  ├─ a.prisma
│  │  │  ├─ b.prisma
│  │  │  ├─ schema.prisma
│  ├─ app2/
│  ├─ app3/
├─ shared/
│  ├─ org/
│  │  ├─ c.prisma
│  │  ├─ d.prisma
│  ├─ person/
│  │  ├─ e.prisma
│  │  ├─ f.prisma

The files under prisma/apps/app1/schema are able to find all references. But the shared models under prisma/shared are not.

I've also tried putting this directory structure under prisma/schema, but then none of the files can find the other models.

Interesting, not finding the refernces sounds like a bug. We'll have a look

prisma db pull will put all new models and enums etc in one file, and keep existing ones in the file they already are. If you want to automatically distribute each model into its own file, I would suggest you write a small script that takes a look at the newly created file with all models, and splits those into one file per model. Shouldn't be too hard following a pattern model [a-z0-9]* {(.*)} (pseudoregex).

We will not add such logic to db pull ourselves, as putting each model into its own file is a super edgecase. And any other way to split between files is highly opinionated and depends on the individual use case.

Or am I misunderstand and overlooking a more general use case that more people will have?

Sounds like you understand~

I saw one comment in discord asking for generation support on db pull, but they implied a need for splitting a certain way (as you say, I'm guessing an individual use case how to split).

I couldn't say if there's a huge use case for this, but there's the thread here now and if there's more of a demand perhaps it'll get votes, or not :)

And thanks for the quick reply, I have confidence now to go ahead and create my own hacky script!

Hacky scripts are the best 😆

All split schema should be under prisma/schema folder and prisma/schema.prisma file should not exist.
If that's already the case for you, please, provide a reproduction. Optimally, open an issue and follow the instructions in the template.

@SevInf I am experiencing the same issue. But I have to note that I have different DBs for different apps.

My folder structure is:

prisma/
├─ generated/
├─ schema/
│ ├─ app1/
│ │ ├─ migrations/
│ │ ├─ schema/
│ │ │ ├─ schema.prisma
│ ├─ app2/
│ │ ├─ migrations/
│ │ ├─ schema/
│ │ │ ├─ schema.prisma
│ ├─ app3/
│ │ ├─ migrations/
│ │ ├─ schema/
│ │ │ ├─ schema.prisma

For example one of my schema.prisma includes this code:

datasource db {
  provider = "postgresql"
  url      = env("DEVICES_DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
  output   = "../../generated/devices"
  binaryTargets = ["native", "linux-musl-openssl-3.0.x", "debian-openssl-1.0.x"]
  previewFeatures = ["prismaSchemaFolder", "multiSchema"]
}

model Device {
  id       Int    @id @default(autoincrement())
  userId   Int
  user     User   @relation(fields: [userId], references: [id]) // Type "User" is neither a built-in type, nor refers to another model, composite type, or enum.

}

Additionally, this code:

npx prisma migrate dev --schema libs/prisma/schema

generates this error for twice(since I have 3 apps):

error: The source "db" cannot be defined because a source with that name already exists.
--> libs/prisma/schema/jobs/jobs-schema.prisma:1
|
|
1 | datasource db {
|
error: The generator "client" cannot be defined because a generator with that name already exists.
--> libs/prisma/schema/jobs/jobs-schema.prisma:6
|
5 |
6 | generator client {

@batusekerci If you use several different schemas inside the same folder, you should run your migrate/generate command multiple times, pointing them to corresponding folder each time, for example:

prisma migrate dev --schema prisma/schema/app1
prisma migrate dev --schema prisma/schema/app2
prisma migrate dev --schema prisma/schema/app4

Thank you thank you thank you ❤️

Are you able to run Prisma Studio locally with this setup?

I have been able to get this working using Prisma Studio, you just need to provide the right params for the --schema argument when running from CLI. I have to use two instances of studio to view both the SQLite and Postgres data however (there's no way afaik to view both with a single instance)

We are aware of that and working on the solution. Formatting action in VSCode that this functionality was working through can not change multiple files, so we probably going to convert those fixes to quick fixes.

from looking at #4720 this seems to still be a pending issue.

Ouch, it's a 2020 issue, so I guess is not a priority. Maybe the more use a custom schema directory the more will need also a custom migration option, I man can only dream :)

You seem to use Prisma version 5.10.2. This preview feature only exists since version 5.15.0. => Updating your installed version of prisma should fix this. :)

To add more context here is my config, I traced the issue could be related that I had multiSchema feature enable

generator client {
  provider        = "prisma-client-js"
  binaryTargets   = ["native", "debian-openssl-3.0.x"]
  previewFeatures = ["omitApi", "postgresqlExtensions", "prismaSchemaFolder", "multiSchema"]
}

I tried both on V5.21.0 and V6.6.0

have the same issue, in my case something broke with v6.6.0

For me the following structure works:

• prisma
  • main.prisma (with generator blocks)
  • migrations
  • schema
    • users.prisma
    • posts.prisma

And in package json

"prisma": {
  "schema": "./prisma"
},

Agree with @jpaylor, docs are confusing.

@iamciroja I'm surprised prisma is finding your schema folder without being pointed to it in package.json. Are you using CLI options?

@rnbrady No, i am not using any additional CLI options
And in package.json (which is located at ) I point to folder called "prisma". So the whole file structure looks like this:

• PROJECT_ROOT
  • prisma
    • main.prisma (with generator blocks)
    • migrations
    • schema
      • users.prisma
      • posts.prisma
  • package.json (points to "./prisma" in "prisma" section)

@iamciroja thanks for replying. That's crazy to me that the "schema" directory in package.json is the parent of the directory called schema. Perhaps you're on an older version < 6.6.0?

From docs:

"As of v6.6.0, you must always explicitly specify the location of your Prisma schema folder. There is no "magic" detection of the Prisma schema folder in a default location any more."

Thank you.