Preview feature feedback: Efficiently `createMany` records at once.

Please share your feedback about the createMany functionality that was released in v2.16.0 in this issue.

Documentation is here.

• If you encounter a bug, please open a bug report in this repo.
• If the feature is working well for you, please share this in a comment below or leave a 👍 on this issue.

If you have any questions, don’t hesitate to ask them in the #prisma-client channel in the Prisma Slack.

[ricardoalmeida]

Very nice feature, thanks!

I see we can use the skipDuplicates that performs “ON CONFLICT … DO NOTHING”, but it will be nice to have the other possibilities the Postgres provides, for example: “ON CONFLICT (did) DO UPDATE…” or “ON CONFLICT ON CONSTRAINT my_custom_pkey DO UPDATE…”. This would allow us a sort of “upsert” for the “bulk create”.

Questions/suggestions:

1. Is there a plan to allow INSERTs as a raw query in case we want to specify the “ON CONFLICT”?
2. The “returning” for bulk create would be nice as well.
3. To better simulate the Postgres “ON CONFLICT”, instead of skipDuplicates, I would provide the option onConflict and the values for this key: “raise”, “replaceAll”, “replaceAllExceptFields”, “nothing”.

[MattGson]

@ricardoalmeida agreed. Probably a separate upsertMany function would fit better with the current API.

Another very handy use case that isn’t discussed much is bulk update. updateMany doesn’t let us set different values for each row we are updating. In SQL this is usually done with a insert on duplicate... where we purposely cause duplicates on every row.

I would look at the knex conflict/merge API for inspiration.

Should be able to achieve the following in Pg, MySQL and SQLite with native on conflict do and on duplicate update:

• Create many rows and ignore key conflicts
• Create many rows and set specific fields on a conflicting row
• Create many rows and choose fields to merge on conflict (i.e. update parts the existing row to match the conflicting row being inserted)

API could look something like:

interface Person {
   id: string;
   first_name: string;
   last_name: string;
}

person.upsertMany({

  data: PersonCreateInput[],
  merge: {
     id: boolean;
     first_name: boolean;
     last_name: boolean;
  },
  update: Person;
})

Although I personally think the update block is not needed and have never found a use for it in the current API (other than just to merge the fields). In the case that both merge and update reference the same field, some precedence would need to be set.