Prisma `Unsupported()` columns can be overwritten about prisma HOT 5 OPEN

Note that a fix for this will also create a proper fix fix for the issue in #24180.

from prisma.

If an Unsupported() column is GENERATED ALWAYS (PostgreSQL)

That is generally not the intended use case for Unsupported(), it was originally meant to only contain the name of the unsupported column to be created. That it allows spaces, and hence can be abused to create SQL that is after the column name is an 🥁🥁🥁 unsupported use case.

That being said, that Prisma reacts with removing a DEFAULT on the next migration because there is no @default on the field is weird. Your guess sounds reasonable:

My guess is that the data Prisma is getting from the shadow database indicates that the textSearch column has a default value (it's GENERATED, after all!), which Prisma interprets to mean that it has a DEFAULT clause.

Probably our Introspection does not differentiate for columns that have an explicit DEFAULT which could be dropped, vs. an implicit because of GENERATED ALWAYS AS.

The direct fix for this problem would be to correctly differentiate here and not generate a migration that tries to drop the DEFAULT that does not even exist.

from prisma.

And...it seems that Prisma refuses to add create and createMany to models with Unsupported() columns--at least if the column doesn't have an @default. If we were to add an @default, though, it would be a problem.

So that's another related bug of Unsupported(). No idea why Prisma wouldn't allow that column to be created using a string or a literal of some kind.

from prisma.

So that's another related bug of Unsupported(). No idea why Prisma wouldn't allow that column to be created using a string or a literal of some kind.

This is not a bug, this is how Unsupported works. Prisma's Query Engine can not read or write and represent data of some types, so does not allow you to use the types - and Unsupported() at least makes it possible to migrate those columns and use the models for some things.

from prisma.

Well, it kills this as a workaround for me. What I need is a "Custom()" type or similar that acts like I'm using Unsupported() but that allows me to create a column with a custom SQL string, and that just leaves it alone. Trust the developer to know how to use the type, and even to flag to Prisma that the type has an implicit default so that it won't demand that we provide that parameter to .create* calls.

Or alternately, for me, real support for full text search on PostgreSQL. Failing that, I can't use Prisma.

At this point I'm investigating Prisma alternatives. I don't really have a choice.

from prisma.