Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add three-way merging to entity updates #512

Closed
ktuite opened this issue Sep 27, 2023 · 2 comments
Closed

Add three-way merging to entity updates #512

ktuite opened this issue Sep 27, 2023 · 2 comments
Labels
backend Requires a change to the API server entities Multiple Encounter workflows

Comments

@ktuite
Copy link
Member

ktuite commented Sep 27, 2023

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.

  • 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.

@github-project-automation github-project-automation bot moved this to 🕒 backlog in ODK Central Sep 27, 2023
@ktuite ktuite added backend Requires a change to the API server entities Multiple Encounter workflows labels Sep 27, 2023
@lognaturel
Copy link
Member

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.

@ktuite
Copy link
Member Author

ktuite commented Sep 29, 2023

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

@ktuite ktuite closed this as completed Sep 29, 2023
@github-project-automation github-project-automation bot moved this from 🕒 backlog to ✅ done in ODK Central Sep 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend Requires a change to the API server entities Multiple Encounter workflows
Projects
None yet
Development

No branches or pull requests

2 participants