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

Automatic and model<>crud coordinating mapping API #461

Open
jasonkuhrt opened this issue Oct 10, 2019 · 1 comment
Open

Automatic and model<>crud coordinating mapping API #461

jasonkuhrt opened this issue Oct 10, 2019 · 1 comment
Labels
needs/discussion Open-ended conversation about something (ideation, design, analysis, ...) scope/projecting Exposing Prisma Models in the GQL API scope/synchronized-projectors type/feat Add a new capability or enhance an existing one

Comments

@jasonkuhrt
Copy link
Member

We currently have no hollistic mapping API. Users can, model-by-model write mappings. But these do not coordinate automatically in any way with the t.crud API. Users need to manually use the type and alias options. This is boring and error prone. When the user screws it up, they get confusing feedback giving them the wrong advice (e.g. "did you forget to export 'Person'?").

const Query = queryType({
  definition(t) {
    t.crud.user() // run time error
    // t.crud.user({ type: 'Person' }) // <-- fixes it
  },
})

const User = objectType({
  name: 'Person',
  definition(t) {
    t.model('User').id()
    t.model('User').email()
  },
})
type Person {
  email: String!
  id: Int!
}

type Query {
  user(where: UserWhereUniqueInput!): User # bug
}

type User {
  email: String!
  id: Int!
  post: Post
}

input UserWhereUniqueInput {
  email: String
  id: Int
}
@jasonkuhrt jasonkuhrt added type/feat Add a new capability or enhance an existing one scope/projecting Exposing Prisma Models in the GQL API needs/discussion Open-ended conversation about something (ideation, design, analysis, ...) labels Oct 10, 2019
@jasonkuhrt jasonkuhrt added this to Backlog in Labs Team via automation Oct 10, 2019
@Weakky
Copy link
Member

Weakky commented Oct 14, 2019

A couple of ideas:

Option 1

We could introduce a t.model.mapsTo('<prismaModelName>') function to avoid having to pass t.model('<prismaModelName>').field() on all calls.

Problems:

  • That would probably break the TS magic we currently have (making the type property required when typeName doesn't map to any prisma model names)

Option 2

(Not sure if feasible)

If all t.model('<modelName>').field() uses the same modelName, then we could infer that typeName maps to modelName. This way it would not even go in the way of composite types if we ever support them (#298)

Problems:

  • Same problem for type-safety though: I think there's no way to compute what's described above at compile time and dynamically make the type property required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs/discussion Open-ended conversation about something (ideation, design, analysis, ...) scope/projecting Exposing Prisma Models in the GQL API scope/synchronized-projectors type/feat Add a new capability or enhance an existing one
Projects
None yet
Development

No branches or pull requests

2 participants