You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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() typing
Today, the typing of auth() function is confined to the User model. To use something out of it, you'll have to use a hack: define a field in User but mark it as @ignore. With "type" construct, one can use a type (completely decoupled from database tables) to back auth().
Wouldn't it be wise to use another keyword other than type as Prisma might have plans on using the same keyword for relational databases, but for a different construct? Something like abstract auth { } or even auth User { } comes to mind.
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-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()
.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:
Other notes:
The text was updated successfully, but these errors were encountered: