You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, if the app is opened in multiple devices/browsers, all have their local storage. Changes can be made but are of course not propagated to other devices.
Changes made by device A can be overwritten by changes made on device B if B is saved after A was saved.
Describe the solution you'd like
There should be an ETag (a hash sum of the recipe's data) that is to be transmitted to the frontend and be returned 1:1 to the backend. If concurrent changes have happened the ETag on the server has changed so the new changes (made by B in the example above) will be rejected by the backend.
The exact structure of the error resolution needs to be defined.
Describe alternatives you've considered
Hard locking of recipes but this contradicts the REST principles.
The text was updated successfully, but these errors were encountered:
The user updating the recipe on device B could be informed that changes have been done by someone else (different device, user, ...) and can decide to overwrite these changes anyway. Errors can be easily recovered once the versioning system (#364, #340) was implemented.
The ETag / hash could be the same used in the versioning system.
Is your feature request related to a problem? Please describe.
Currently, if the app is opened in multiple devices/browsers, all have their local storage. Changes can be made but are of course not propagated to other devices.
Changes made by device A can be overwritten by changes made on device B if B is saved after A was saved.
Describe the solution you'd like
There should be an ETag (a hash sum of the recipe's data) that is to be transmitted to the frontend and be returned 1:1 to the backend. If concurrent changes have happened the ETag on the server has changed so the new changes (made by B in the example above) will be rejected by the backend.
The exact structure of the error resolution needs to be defined.
Describe alternatives you've considered
Hard locking of recipes but this contradicts the REST principles.
The text was updated successfully, but these errors were encountered: