Error in "create" logic ?
Hey !
I've noticed something while creating an object.
This is my model:
So when I call my create route I'm using Prisma.BrickCreateInput and this is the code generated by Prisma for it:
There is no "id" field as expected.
But when I'm trying to create a brick, if I pass an "id" to it, it will erase the default autogenerated id (see picture 1).
So I'v tried to destructure it (picture 2) but I get an error "property id doesn't exist on type BrickCreateInput".
I've noticed something else too, if you add an extra field let's call it "extra" and you also pass and "id", and try to submit it you get this error: "Unknown argument id. Available options are marked with ?.", but this is not returned when you pass only the "id" param.
Is it attended ? And is there any way to ignore extra fields instead of throwing an error ?
2 Replies
Hi @Kynda 👋
The
BrickCreateInput
type does not include the id
field because id
is set to be auto-generated. Prisma Client automatically handles the generation of this field, and it is not intended to be set manually during creation.
When you attempt to pass an id
field while creating a record, Prisma interprets this as an override to the default behavior.
Prisma currently throws an error when extra fields are passed to the create
method. This behavior is intentional to ensure type safety and prevent unexpected data from being processed. There is an open issue to allow passing of extra fields.GitHub
Don't throw error when passing objects with additional fields · Iss...
Problem Typescript actively uses duck typing, which allows us to significantly reduce the amount of code in comparison with other languages, since we do not need to write many adapters and intermed...
Are you trying to create a new brick, eg it would actually need it's own id, or creating a "deep copy" (eg totally new brick with the same data as the old)? If it's the later, delete the id field prior to insertion, if it's the former you could just create a foreign key relationship and not need any other fields than the original brick's id. (there are many legit use cases for duplicating data fyi, correctness is a gradient after all)