Update multiple items in single mutation

[tomsimpkins]

What would you like to be added:
Update of multiple items via a single mutation:

mutation {
  plans(update: $data) {
    id
    name
  }
}

where data is:

[{ id: 10, name: "plan1" }, { id: 11, name: "plan2" }]

Why is this needed:
I don't believe this is possible currently without implementing a custom mutation, and I think this abstraction is generically helpful.

The documentation suggests that this is possible with upsert:
https://github.com/dosco/graphjin/wiki/Guide-to-GraphQL#bulk-upsert

However, I haven't got this to work successfully via the packaged Graphjin UI - the error message coming back is complaining there is a missing where clause, implying the primary key is not matched if this behaviour is indeed intended.

I'm very aware this might be my misunderstanding, so apologies in advance if that is the case

[MIRO1990]

I have the same issue too, I am getting an error when trying to update more than one item at once

[dosco]

This is not supported as yet but we could definitely add it

[ClassicSours]

Working on a feature now using y'alls platform and bulk upserts would be amazing to have. If i have a large array of rows being able to update/insert rows in our table that is unique by an unchanging column in a single connection as opposed to opening a connection for each one would be a real game changer.

[jquintozamora]

I'm having the same issue, is there any ETA in place for solving this? thanks!

[ClassicSours]

I'm having the same issue, is there any ETA in place for solving this? thanks!

this may not be the solution you are looking for but how i was able to side step this issue was moving from the trigger updating my audit table to going the other way

instead of inserting to my mutable table with a bulk upsert and having a trigger update the "immutable" audit table we instead only bulk insert into the audit table and have a trigger on insert into the audit table that per row updates/inserts into our mutable table we actually care about upserting on

hope this helps/save yall some time.

[MIRO1990]

@ClassicSours as I understood from your answer, you are using upsert to either update if the row exists of insert if it doesn't.
if that's the solution you are suggesting, then unfortunately that won't quite work as expected, because the validation on insert is different from the validation on update.
For example, if you are inserting a new row, then you would want to have some required columns to complete creating a new row, but with the update case, you don't need all the required columns to update the row, you would only need one column to be updated for example, in that case, the upsert would fail and ask to include all the columns values for update in order to match the validation on insert , so it's not ideal in that case.
please let me know if I misunderstood your idea.
Thank you :-)

[ClassicSours]

@ClassicSours as I understood from your answer, you are using upsert to either update if the row exists of insert if it doesn't. if that's the solution you are suggesting, then unfortunately that won't quite work as expected, because the validation on insert is different from the validation on update. For example, if you are inserting a new row, then you would want to have some required columns to complete creating a new row, but with the update case, you don't need all the required columns to update the row, you would only need one column to be updated for example, in that case, the upsert would fail and ask to include all the columns values for update in order to match the validation on insert , so it's not ideal in that case. please let me know if I misunderstood your idea. Thank you :-)

that is essentially correct, we have a couple of columns we want the database to have ownership over, however the rest should be user input with a unique primary key that defines each row. Ideally upsert would either insert a new row, or update an existing row with matching primary key. Being able to define some "on conflict" logic for the update case would likely be needed as well as that is what the trigger we have made is essentially doing.

[MIRO1990]

@ClassicSours
Right got it, as I understood, you have implemented a way for the trigger to resolve any conflicts between update and insert by accessing the database by the primary id.
Thanks for explaining.

[MIRO1990]

@ClassicSours seems like GraphJin doesn't allow upsert mutation on a VIEW because VIEW doesn't have primary key or unique id that Graphjin requires.
Do you know any possible solution for this problem?