Expand our Prisma support (enum, type, other dbs, ...)

[Martinsos]

Wasp is heavily using Prisma for the DB layer of web app, but it doesn't yet utilize everything that Prisma offers. Here we can track some of the bigger items that we recognize would be cool to support in the future when we are ready / feel the need for them:

1. Support for enum and type declarations in PSL. enum we should certainly add, while type is for now used for MongoDB, so probably no rush until we decide to also support MongoDB, or until type gets wider usage. Btw type is interesting since it pushes PSL closer to being the full data schema, closer to what GQL can do, and closer to what Wasp will need in the future in any case.
2. Support for other databases next to Postgresql (they even support nosql databases like mongo and cockroach).
3. [DONE] Seeding of the db: Support seeding the database #569
4. Better utilize their migrations support: Support data migrations & provide best practices and examples #330

[Martinsos]

Since Prisma 4.9, Prisma now also has Views!

https://twitter.com/ryanchenkie/status/1616487561169440769

https://images-ext-1.discordapp.net/external/WdWlpcUrrX9h0LXy30op1P01vwBDfBTW3krrOgtyQb4/https/pbs.twimg.com/media/Fm7qeSCWAAIwmNd.png

So we should also look into that.

[Martinsos]

Makes sense to solve this together with #887 .

[ldeavila]

To address this, I used the existing seeder functionality as a workaround to execute a function that created the enum. This make me think if it would perhaps be more efficient to add direct support for executing DDL scripts within the framework?

Instead of continually expanding support for every specific Prisma modeling feature, a combination of DML (seeder functions) and DDL capabilities could provide a very robust and flexible solution. I believe this approach would cover the vast majority of use cases.

[Martinsos]

That is an interesting idea! But it is a bit hacky, and the solution we have in mind to fix all this goes the other way -> it lets you write Prisma directly in Prisma files, which should solve all of these issues. So let's see how that goes, and if that works we rae great, if not I think we can examine your suggestion again!

[sodic]

User asking for Enums: https://discord.com/channels/686873244791210014/1220352081970466908/1220607862078836766.

The same user is also not a fan of having Prisma stuff inside Wasp and would prefer a separate schema.prisma file (the message below the linked one).

Full quote:

For the moment it's fine, except for the enum : I really need it in Prisma and it was almost a no-go to not have it...
Ideally it would be nice to have the schema.prisma at the root with all the Prisma features, and to not handle it in main.wasp (already a really big file here)

[Martinsos]

Nice, ok that is the plan!

[sodic]

One more relevant comment: https://discord.com/channels/686873244791210014/920312576133443634/1220434636824514722

[Martinsos]

This will mostly be solved by the solution we are implementing for #887 , which is moving entities from main.wasp to prisma.schema file. The initial step of this effort is #2002 .

[infomiho]

enums are now supported since #2035

This doesn't add support for views or types or other DB types.

[Martinsos]

@infomiho how is it that we can't use views or types? Can't we just write those in prisma.schema and voila we use them?

[infomiho]

Our parser doesn't yet support views or types, when we add support it will work 👍

[infomiho]

We have support for views and type since #2179