Mutation type when using Prisma to create connected records

[timReynolds]

Hi I've just started using blitz and came across an interesting side effect of reusing the Prisma types in mutations when creating nested relationships.

As per the prisma documentation you can do the following;

const userAndPosts = await prisma.user.create({
  data: {
    posts: {
      create: [
        { title: 'Prisma Day 2020' }, // Populates authorId with user's id
        { title: 'How to write a Prisma schema' }, // Populates authorId with user's id
      ],
    },
  },
})

This in itself is fine, however due to the reuse of of the Prisma generated *CreateArgs type in the mutation if you pass something like the following data structure from a form you'll get a type error as the mutation expects the shape of data to match that being passed into the Prisma create method which includes the extra create keyword.

{ 
  data: {
     posts: [
        { title: 'Prisma Day 2020' }, 
        { title: 'How to write a Prisma schema' },
      ]
  }
}

Note: this shape is probably closer to what you'd expect the form to output if using something like Formik FieldArray

This was touched on in this discussion also and I agree that reshaping the data in the migration itself is probably the correct approach.

What I found misleading however is the reuse of the Prisma types for the mutation. My guess is this has been done for convenience and this isn't something many people are probably doing. Ideally the type for the mutation would be generated and not include the Prisma specific types but my guess is this would be a considerable amount of effort.

In my local setup I've change the mutation type to still use those in Prisma but switch to the *CreateInput omitting the relationship and then adding it to the type using the entities *CreateInput, this is probably easier to understand with a code example pulled from what I've been working on;

import { Ctx } from "blitz"
import db, { Prisma } from "db"

interface CreateFieldData extends Omit<Prisma.FieldCreateInput, "options"> {
  options: Prisma.Enumerable<Prisma.FieldOptionCreateWithoutFieldInput>
}

interface CreateFieldInput {
  data: CreateFieldData
}

export default async function createField({ data }: CreateFieldInput, ctx: Ctx) {
  ctx.session.authorize()

  const field = await db.field.create({ data: { ...data, options: { create: data.options } } })

  return field
}

I mostly opened this discussion for anyone else that discovers this but on reflection it might be worth considering updating the code generator for the scaffolding command to do something closer to the types outlined above.

Would be interested to hear peoples thoughts.

[timReynolds]

Thought it was worth throwing some more notes down while working with mutations a little more.

1. Using the same approach for update wasn't as clean
2. You can import the model types from Prisma so if you've got a model called Field like my example above you can import that type but not via the Prisma exported from db. For it to find the types you want you'll want to grab them from @prisma/client

// This doesn't include the model types 
// import db, { Prisma } from "db"

// However this will 
import Prisma from "@prisma/client"

// So you can then do 
const field: Prisma.Field = {}

[flybayer]

This should work:

import db, { Field } from "db"

const field: Field = {}

And thanks for this discussion!