Description
We can introduce a pure "type" construct into ZModel to complement the "model" construct. Contrary to "model", "type"s are not mapped to database tables and are purely for type-checking purposes.
Here are some scenarios that can be enabled by type:
-
Strong-typed JSON field [Feature Request] Strong-typed JSON fields #784
type Profile { bio String avatar String } model User { ... profile Profile @json }
-
Type-checking for plugin options [Feature request] Support implicit inversed relationship #613
Today, plugin options are just plain arbitrary properties, and there's no parse-time checking at all. With the "type" construct, plugins can define their own options type, and users can enjoy parse-time error reporting and IDE auto-completion.
-
More flexible
auth()
typingToday, the typing of
auth()
function is confined to theUser
model. To use something out of it, you'll have to use a hack: define a field inUser
but mark it as@ignore
. With "type" construct, one can use a type (completely decoupled from database tables) to backauth()
.type MyAuth { ... @@auth() }
-
Foundation for modeling non-database entities
To support modeling entities residing in other systems (3rd-party APIs, e.g., a stripe payment). Related to [Feature Request] ZenStack for API integration #563
-
Enable reusing attributes at the field level
Propsed by Erik from Discord:
type Slug extends String @db.VarChar(50) @regex('^[0-9a-zA-Z_]{4,50}$') @default(cuid()) @unique model Post { slug Slug }
Other notes:
- Prisma already uses the "type" keyword, but it's for MongoDB only. This feature will repurpose this keyword for relational databases.