Tutorial 10 - Using Mutations to Edit a Record

introduction last time we looked at how you can use mutations to create a record this time, we will look at a mutation to update a single record the syntax is very similar to creating a record, but the main differences are 1\) using a different mutation type 2\) we need to pass in an id to identify the record which needs to be changed steps to edit a record step 1) add the mutation keyword all queries started with the query keyword; mutations start with the mutation keyword mutation edititem { } we've also named our mutation edititem step 2) add the recordupdate mutation type mutation edititem { record update() { } } step 3) add the id of the record which should be updated in this example, we'll add the id as a variable mutation edititem($id id!) { record update(id $id, record {}) } note, we don't need to add an object for the id as we might when filtering a query step 4) define the new properties in the record object as with record create mutations, the record object defines the properties the record will have after the mutation has run any properties you set will be updated any properties you omit will stay in their current state mutation mymutation($id id!) { record update( id $id record { properties \[ { name "module field 3 1", value "updated blog title" } ] } ) } you do not need to specify a table by default, the record will remain in its current table attempting to change the table may not be supported on siteglide as the new table would not have compatible fields as in our last tutorial, it is possible to pass in properties as a single large json variable, if you see a convenience in doing so step 5) add results as in the last tutorial, it is required to add something to the object which returns with the results of the mutation this can be useful to confirm results and show you what has changed however, if you don't need many details, the best performing option is just to ask for id mutation mymutation($id id!) { record update( id $id record { properties \[ { name "module field 3 1", value "updated blog title" } ] } ) { id } } a successful mutation result will look like this { "data" { "record update" { "id" "96" } } } handling race conditions imagine you have two different forms, each with an automation attached to them and you want to count how many times the automation runs you set up a webapp with a custom integer field each time the automation runs, you query the webapp, get the current count add 1 to the value with the add liquid filter and update the count with a record update mutation 9 times out of 10, this will behave as expected, but what if two people submit the form at the same time? if both automations check the current count at the same time, they will both read the same value e g 5 and after adding 5, will save 6 as the updated count in the database even though the automation ran twice, the count would only increase by 1 it is to combat this scenario that record update contains the following special operations array append will push the provided value to the end of an existing array stored in a property array remove will remove the provided value from an existing array stored in a property, (wherever in the array it currently is) decrement will reduce an existing integer value by the provided integer value (could be 1 or some other integer) increment will increase an existing integer value by the provided integer value (could be 1 or some other integer) in our example, we could do the following mutation mymutation($id id!) { record update( id $id record { properties \[ { name "webapp field 1 1", increment 1 } ] } ) { id } } this safely increases the counter by one per mutation run, even if the two mutations are triggered by liquid simultaneously there is no need to query the existing value summary nice work following through this tutorial if you want to try updating users, you can experiement with the user update mutation next time next time, we'll look at how to delete records