[Introspection] Decide on a way forward for introspection of types our internal type system currently cannot represent

[tomhoule]

The example of this problem we came across in https://github.com/prisma/prisma-client-js/issues/507 is postgres' tsvector. It is an opaque data structure that doesn't really make sense as a string and can only be constructed through postgres expressions, so it is not currently doable through prisma-client (outside of the raw API).

We currently introspect tsvector columns as String (the fallback for types we do not handle yet), but prisma will fail to read or write to these columns. The problem is especially acute when we these columns are not nullable.

The reasonable choice for now would probably be to ignore these columns when introspecting, and signal that we did that with a warning.

cc @janpio

[janpio]

Long term we definitely want to support all possible types. Supporting them we track under the name "native database types".

But right now all types that can not be represented by one of the types we already support, or via a fallback to a string are problematic. That means that we have to find a guardrail for these types so user's can build applications with these types anyway.

I agree that we should remove them from the models by commenting them out. This can become problematic if the columns are not nullable and there is no default value set on a database level. There might be dirty hacks to work around that in some way, but we do not really want to start getting into that.

So tasks are:

1. Find out which types we can not properly represent right now.
2. Decide which ones of those we can not support via String.
3. Implement commenting out of these types in Introspection, including a warning given via CLI.
4. Look at all cases of that via the warnings generated during Introspection, and see if any of them are not nullable or are special in any other way.

[schickling]

In case we're indeed commenting out unsupported fields we should also disable write operations (in the Prisma Client) that could possibly fail (e.g. trying to create a new row with a required value missing).

[janpio]

Interesting.
As far as I know we do not have a real way to get that from the schema, unless we would put the commented out fields in the DMMF as well (so parse them from the schema and have them in the internal representation) and then react to that in the Client (If there is a commented out field, that does not have a default value, do not allow this action).

[janpio]

For now we decided to implement the guardrail to comment all of these out in the schema: #1812 When this is done, we will check for sideffects and possibly implement workarounds for these.

[janpio]

Guardrail is implemented and merged, ripple effects (including @schicklings's comment) are now tracked in #1912 🚀