<@U0RQY0KK5> Has anything changed in Prisma relate...
# orm-help
f
@nilan Has anything changed in Prisma related to
updateManyEntities
in
1.20-beta.1
? my generated
prisma.graphql
changed every
updateManyX
parameters from
data: XUpdateInput
to
data: XUpdateManyInput
and now my app fails (
got invalid value {...}; Field "..." is not defined by type XUpdateManyInput.
). I can’t see related breaking changes in the release notes before
1.20-beta.1
so I assume the breaking change is in this version which is not yet published (but development servers are using it)
Copy code
input ShipmentUpdateManyInput {
  create: [ShipmentCreateInput!]
  connect: [ShipmentWhereUniqueInput!]
  disconnect: [ShipmentWhereUniqueInput!]
  delete: [ShipmentWhereUniqueInput!]
  update: [ShipmentUpdateWithWhereUniqueNestedInput!]
  upsert: [ShipmentUpsertWithWhereUniqueNestedInput!]
}
Copy code
input RecipientUpdateManyInput {
  phoneNumber: String
  email: String
}
That’s weird 🤔 , why would an entity have create, connect etc, and another entity normal fields instead for the same type of input?
Something related to these inputs was changed 5 days ago in beta branch but I’m not sure if it’s connected to this issue: https://github.com/prisma/prisma/commit/20b7f369d6b95c0c38b70526fbd58f3efd871549
d
Yes, we changed these inputtypes but haven’t cut a new release with this yet, which is why there are no release notes about the breaking change yet. This change was necessary since the schema contained nested mutations within updateMany which were not being executed and were confusing people. This change removes those from the schema.
The bottom one you posted seems to correct to me. The updateManyInput should only contain scalar fields now. The top one looks weird.
f
@do4gr That’s what I get when I deploy and get back the updated
generated/prisma.graphql
I have two entities,
shipment
and
shipmentLineItems
that contain
create
,
connect
, etc in the UpdateManyInputs. Every other entity contains scalar numbers 🤷‍♂️
d
Is shipment in a relation but does not have a backrelationfield to it’s parent?
f
If I understood correclty, yes. There is another entity
ShippingReport
which has an array of Shipments. A Shipment has no link back to ShippingReports
same for
ShipmentLineItems
, a
Shipment
contains many line items but they don’t have link back to the Shipment
d
Ok, thanks. I think that explains the problem. We are generating similar names for different input type use cases. I’ll change the newly created name for the updateManyInput. RecipientUpdateManyMutationInput should be both more clear and avoid possible duplication problems.
Thanks for reporting this!
f
Awesome, thanks!