Directly updating mysql database bypassing prisma-bindings: caveats?

prisma

#1

Hi,

I have to update about 5K records of a single table from a custom resolver. I went the traditional way with prisma-bindings, using code I found somewhere in this forum:

const updates = [];
for (let i = 0; i < stocks.length; ++i)
  updates.push(()=>
    db.mutation.updateStock({
      where: {...},
      data: {....},
    },"{id}"));

const LIMIT = 10
await Bluebird.map(
    updates,
    (u) => u(),
    { concurrency: LIMIT }
  );

I found this terribly slow. On my local deployment using docker, it can take like 30 seconds.

Then I installed mysql2 bindings for node, and replaced the calls to prisma-bindings with direct updates to the db. It takes about 2 or 3 seconds.

So, the question is, what could be the potential problems in bypassing graphql-bindings altogether the way I’m doing it? I would like to keep using prisma, since for all my endpoints expect one (this one where I’m doing a batch update) it is of great help.

Thanks!
Marco


#2

Could you use updateManyStock? See Batch mutations - Prisma docs


#3

Hi meep, thanks for the reply.

It doesn’t show in the pseudocode that I’ve pasted above, but what goes inside “data” is a function of the loop variable “i” and other data that I use to update the stock. From what I understood about the “updateMany” it is supposed to set the same value to distinct records. Here I want to set distinct values to distinct records.


#4

That’s a great use case - we’ll soon detail how raw DB access could look like, which would be a great fit for your situation. Please upvote and subscribe here:


Some mutations fail when no concurrency limit