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
We've talked a lot about the merge strategy for updating entities when the versions are in conflict, including a smart merge that will diff the new data with the data of the base version to figure out the intended delta, and then apply that delta to the latest data.
This issue is about implementing this and testing it, and possibly thinking about what information needs to be saved along the way.
store the delta?
store the data that was parsed from the submission so deltas can be recomputed?
flag if there was a deeper field conflict?
This issue may spawn another issue about exposing conflict details at the version/field info through the API but not sure yet.
The text was updated successfully, but these errors were encountered:
My recollection was that we weren't going to do three way merging and would instead do last-received-wins with detection of
"simultaneous updates": the last received updating submission's base version is not identical to the server's current version and there is no overlap between the properties updated by this submission and properties changed by any updates made since the last received submission's base version
"conflict": the last received updating submission's base version is not identical to the server's current version and there is overlap between the properties updated by this submission and properties changed by any updates made since the last received submission's base version
IIRC, we mostly reached this conclusion based on the assumption that updates from submissions would generally be diffs already. That is, if a property isn't changed by a form, it wouldn't generally be sent. That assumption would be incorrect if users decide to build forms that are more for data management than worfklow management so we would track frequency of conflicts and reconsider more sophisticated merging if they happened a lot.
Ah yes, sounds good! I'm going to close this issue but copy over the note about defining conflicts to this other issue that is specifically about deciding how to manage conflicts. #511
Depends on #509 and #511
We've talked a lot about the merge strategy for updating entities when the versions are in conflict, including a smart merge that will diff the new data with the data of the base version to figure out the intended delta, and then apply that delta to the latest data.
This issue is about implementing this and testing it, and possibly thinking about what information needs to be saved along the way.
This issue may spawn another issue about exposing conflict details at the version/field info through the API but not sure yet.
The text was updated successfully, but these errors were encountered: