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

Handle entities that have been removed on the server #6132

Merged
merged 26 commits into from May 21, 2024

Conversation

seadowg
Copy link
Member

@seadowg seadowg commented May 10, 2024

Closes #6011

Why is this the best possible solution? Were any other approaches considered?

The big change here is that our locally stored entities (of type Entity) can now be "offline" (they only exist locally) or "online" (they exist locally and on the server). This concept refers to the entities ID rather than its version: we might have made an update locally that's not on the server yet to an entity we know is "online". Entities become "online" once they've been seen in a form's entity list. As part of this change, I've updated the language we use in the code to reflect it better.

As noted in the issue, there isn't a way that we could handle one of the cases (a form deleted on the server that has never been "seen" by the client in an entity list) without adding new communication with the server. This is something that's being actively discussed with the Central team.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Not much has changed other than entities so testing can probably be restricted to that.

One thing to note is that entities will likely be cleared when upgrading from one version of Collect to another with the current implementation. As discussed here, this is just a temporary caveat while the features are experimental so allow us to iterate faster.

Before submitting this PR, please make sure you have:

  • added or modified tests for any new or changed behavior
  • run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
  • added a comment above any new strings describing it for translators
  • verified that any code or assets from external sources are properly credited in comments and/or in the about file.
  • verified that any new UI elements use theme colors. UI Components Style guidelines

@seadowg seadowg marked this pull request as ready for review May 13, 2024 12:37
@seadowg seadowg requested a review from grzesiek2010 May 13, 2024 12:37
}
} catch (e: Exception) {
entitiesFile.delete()
entitiesFile.createNewFile()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah good spot! We don't actually need to delete the file itself as we just treat the file as empty and then override next time we mutate (as we always do anyway). I can remove the delete/createNewFile call.

We write the whole file again when mutating, so treating the
file as empty is good enough.
@seadowg seadowg requested a review from grzesiek2010 May 21, 2024 11:29
@grzesiek2010 grzesiek2010 merged commit 340b977 into getodk:master May 21, 2024
6 checks passed
@seadowg seadowg deleted the deleted-entities branch May 21, 2024 12:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Delete local entities that have been deleted/archived/unassigned from server
2 participants