This is a new action type, that will be handled in one of two ways:
If the relevant service has an endpoint matching action type UPDATE, the action will be prepared and mutated with this endpoint, and sent to the transporter. This is no different than how we treat e.g. a SET action, except it will match a different endpoint.
If there’s no endpoint matching UPDATE, we will instead dispatch the action as a GET (not changing anything but the action type), and then merge the data from the original action with the result of the GET (with priority to the original values), before sending a SET action with the merged data and all other params from the original action.
This way, services may support dedicated update endpoints to do more direct updates, e.g. by running update queries directly in a database, while for other services the behavior will be mimicked through the get and set operations – changing only the fields given in the original data.
This is a new action type, that will be handled in one of two ways:
UPDATE, the action will be prepared and mutated with this endpoint, and sent to the transporter. This is no different than how we treat e.g. aSETaction, except it will match a different endpoint.UPDATE, we will instead dispatch the action as aGET(not changing anything but the action type), and then merge the data from the original action with the result of theGET(with priority to the original values), before sending aSETaction with the merged data and all other params from the original action.This way, services may support dedicated update endpoints to do more direct updates, e.g. by running update queries directly in a database, while for other services the behavior will be mimicked through the get and set operations – changing only the fields given in the original data.