Problem
It is difficult to maintain the schema and using the client for applications dependent on types that are unsupported by Prisma.
More specifically, whenever introspecting the database, columns of unsupported types are commented out. In these situations, using migrate to update the database schema again later will trigger the deletion of the column which isn't wanted.
Suggested solution
Have a way to keep columns of unsupported types around in the database, even if not having these usable within the Prisma client.
Possibilities:
model Bla {
myField Unsupported("MACADDR")
}
// Or
model Bla {
myField Unsupported @Unsupported("MACADDR")
}
Additional context
Using $queryRaw on unsupported field types may trigger errors depending on the type as the Rust engine may not be able to deserialize it properly. I assume that going into that would probably mean to look into supporting these field types as I suspect that could be equivalent to actually supporting them.
Problem
It is difficult to maintain the schema and using the client for applications dependent on types that are unsupported by Prisma.
More specifically, whenever introspecting the database, columns of unsupported types are commented out. In these situations, using migrate to update the database schema again later will trigger the deletion of the column which isn't wanted.
Suggested solution
Have a way to keep columns of unsupported types around in the database, even if not having these usable within the Prisma client.
Possibilities:
Additional context
Using
$queryRawon unsupported field types may trigger errors depending on the type as the Rust engine may not be able to deserialize it properly. I assume that going into that would probably mean to look into supporting these field types as I suspect that could be equivalent to actually supporting them.