Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Support for non-model types #783

Open
ymc9 opened this issue Oct 23, 2023 · 1 comment
Open

[Feature Request] Support for non-model types #783

ymc9 opened this issue Oct 23, 2023 · 1 comment

Comments

@ymc9
Copy link
Member

ymc9 commented Oct 23, 2023

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:

  1. Strong-typed JSON field [Feature Request] Strong-typed JSON fields #784

    type Profile {
        bio String
        avatar String
    }
    
    model User {
        ...
        profile Profile @json
    }
  2. 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.

  3. 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().

    type MyAuth {
        ...
        @@auth()
    }
  4. 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

  5. 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.
@AmruthPillai
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants