support multiple per-row updates in a single mutation

Currently we allow updating multiple rows (through where) but all of them will get the same update. We need to add support for cases where the updates are different for each row, say you want to set name to Hello for the row with id=1 and to World when id=2. Something like this maybe?

{
  update_user_many(
    updates: [
      { where: {id: {_eq: 1}, _set: {name: "hello"}},
      { where: {id: {_eq: 2}, _set: {name: "world"}}
    ]
  ) {
    affected_rows
  }
}

Notes:

1. What happens when there is overlap across the where conditions? What would affected_rows and returning return?
2. Constructing the updates argument would need a bit of a boilerplate.

Maybe we can simplify the api to just use the primary key/unique constraints?

{
  update_user_many(
    updates: [
      { id: 1, _set: {name: "hello"}},
      { id: 2, _set: {name: "world"}}
    ]
  ) {
    affected_rows
  }
}

We can probably use update .. from as suggested here: https://stackoverflow.com/a/18799497

[eviefp]

I’m happy to announce this feature has been merged: https://github.com/hasura/graphql-engine/commit/84366c92818e32c04093db9f8ba2913243a8c5d9.

You should be able to use this feature in the next release!

During these couple of weeks, we’ve iterated a few times on the solutions and ended up being able to provide a bit more features than originally anticipated. You can read about it in the commit’s CHANGELOG.

Essentially, this feature will create a new mutation field named update_<table>_many. This will take a list of updates, each with a where clause along with its own set/inc/etc., clause. These updates will run in sequence. The return type will be the equivalent of running each update separately. The advantage is that everything is being ran in a single transaction, so if one of them fails, everything gets rolled back.

We’re excited to hear back from you and get feedback on this new issue! Let us know how you end up using it.

[noel-dolan]

Wow! First posted in 23 Aug 2019 and still not a feature! This is exactly what I was/am looking for too, I won’t hold my breath! :p upsert really isn’t an option as all fields are required which would be other data being wiped. Surely this should be high up the list of features that are added! 😕

Edit:

Looks like the following might be a viable, if not quite perfect, solution - just add an alias to each update request.

mutation myUpdates{ update1: update_users(where: {id : 1}, _set: { value: 10 }) { affected_rows } update2: update_users(where: {id : 2}, _set: { value: 15 }) { affected_rows } update3: update_users(where: {id : 3}, _set: { value: 20 }) { affected_rows } }