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

Sync patient data from server to user #16

Closed
6 tasks done
ssrihari opened this issue May 16, 2018 · 2 comments
Closed
6 tasks done

Sync patient data from server to user #16

ssrihari opened this issue May 16, 2018 · 2 comments

Comments

@ssrihari
Copy link
Contributor

ssrihari commented May 16, 2018

  • Get new/updated patients from server
  • Save the timestamp of the latest record synced with server
  • Log validation errors
  • Mark patients with validation errors as invalid
  • Finish unit tests
  • Save phone numbers

We need to think this through
We need to batch records that need to be sent from server to user. Do we use pagination mechanisms? How do we define last_sync_at? Should we record server_updated_at in addition to device_updated_at?

@ssrihari ssrihari added this to This Iteration in RedApp May 16, 2018
@ssrihari ssrihari moved this from This Iteration to Doing in RedApp May 17, 2018
@ssrihari
Copy link
Contributor Author

ssrihari commented May 17, 2018

Further thoughts:

  • We should store updated_on_server_at during the POST request, so that we can compute the diff of records to send to each device during the sync.
  • Sync all records first time. First time syncing should be indicated by absence of updated_on_server_at or a more specific field in the request.
  • We should separate the notions of request and response timestamps from updated_at timestamps of the records. To compute the diff, we should only ever use timestamps of records, not request/response timestamps.
  • At the end of the GET request, we should compute the latest_record_timestamp, and send that to the device with the response. The device can send this value with the next request to receive the next batch of records. This makes the pulls batch-able as a stream of independent requests, without needing to keep a track of when the sync 'ends'. Do not use last_sync_at for this reason.

Things the device/front-end should do:

  • Devices should store latest_record_updated_at per API endpoint.
  • Devices should send a value denoting the number of records, or batch_size they want. This can change per request.
  • Devices should push before they pull

Things we're not doing right now:

  • If we want to send back only the diff of changed records per user, we should store last_updated_by_user_id
  • If we use last_sync_at, it should be set at the beginning of the GET request, not the end.
  • We could include a margin of error in the time range we use to retrieve records to sync, to account for some race conditions or time differences across devices/servers.

Patterns for office mobile syncing architecture: https://www.dre.vanderbilt.edu/~schmidt/PDF/PatternPaperv11.pdf

@ssrihari
Copy link
Contributor Author

@timcheadle: @govindkrjoshi and I are in agreement about the above. Thoughts?

@ssrihari ssrihari moved this from Doing to PR Review, QA in RedApp May 22, 2018
@ssrihari ssrihari moved this from PR Review, QA to Doing in RedApp May 22, 2018
@ssrihari ssrihari moved this from Doing to This Iteration in RedApp May 25, 2018
@ssrihari ssrihari moved this from This Iteration to Doing in RedApp May 29, 2018
@saket saket moved this from Doing to PR Review, QA in RedApp Jun 5, 2018
@saket saket moved this from PR Review, QA to Done in RedApp Jun 5, 2018
@timcheadle timcheadle removed this from Dev+QA Complete in RedApp Jul 10, 2018
@saket saket closed this as completed Nov 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants