As the documentation states, update
is the proper operationType to use in most situations.
update | Update an existing record. Only the fields you specify are changed.
It's always possible that the record was updated by another client between the time you read it and tried to apply new updates. The recordChangeTag
is how the server knows which version you read, which is why the documentation states that you need to send it along in an update operation.
If operationType is update, set the recordChangeTag key to the value of the existing record [in the record dictionary].
When you try to update a record that was already updated by someone else, you will receive a conflict from the server because your recordChangeTag is old and you should handle that conflict in whatever way makes sense in your app. Maybe you want to tell the user and maybe you just want to merge the changes.
In special situations you might want to force the update to succeed. In that case, you can use the forceUpdate
operationType, telling the server to ignore conflicts and take this update, and in this case you don't have to include the recordChangeTag
.
forceUpdate | Update an existing record regardless of conflicts. Creates a record if it doesn’t exist.
If you use the normal update
operationType and you receive a success (not a conflict) then the record should definitely be updated on the server. If it's not then something else is happening.
It is worth mentioning that you might find it more convenient to use the RecordsBatchBuilder when sending changes to the server. Here is an example of what you can do with it:
myDatabase.newRecordsBatchBuilder()
.createOrUpdate(record1)
.create(record2)
.update(record3)
.forceUpdate(record4)
.delete(record5)
.commit()
As you can see, it handles a lot of the options for you.