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

Switching from saving lastUpdated on source, to saving lastUpdated on targets #61

Open
longstone opened this issue Apr 7, 2022 · 3 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@longstone
Copy link
Collaborator

From my point of view, changing the behavior would need some bigger refactoring.

See discussion in PR #38 :

I think that persisting the information to which destination the upload was successful would be the right way, at least for my use case. It would be best to check if there is some destination that had not been updated and download data from withings only if this is the case.

Support wanted here for fixing this behaviour.

@longstone longstone added enhancement New feature or request help wanted Extra attention is needed labels Apr 7, 2022
@longstone longstone changed the title Feature: Switching from saving lastUpdated on source, to saving last updated on targets Feature: Switching from saving lastUpdated on source, to saving lastUpdated on targets Apr 7, 2022
@stynoo
Copy link
Contributor

stynoo commented Apr 10, 2022

Whow, lots of new activity since I last checked! Thanks for continuing with this project!

I solved this (see fork) with logging to a local .csv file on successful sync only. Combined this with a lookup in that csv file before each sync and never had duplicate entries in Garmin connect since.

Added bonus is local logging and history of the measurements in a format that can easily be imported in other scripts/services.

@stynoo
Copy link
Contributor

stynoo commented May 15, 2022

@longstone my solution based on the above mentioned csv input can be found here

By default it is now fetching measurements starting from 3 days ago, comparing the measurements to what is found in the local csv, if found: discard, if not found: upload.

Notable changes to the debug output are:

2022-05-15 11:51:27,267 - root - INFO - Fetching measurements from 2022-05-11 22:00 to 2022-05-15 21:59

2022-05-15 11:51:27,708 - root - DEBUG - Record for 2022-05-15 10:44:01 not found in csv file... adding...
2022-05-15 11:51:27,709 - root - DEBUG - Record for 2022-05-12 08:48:17 found in csv file... skipping...

2022-05-15 11:51:44,283 - root - DEBUG - /config/withings-sync-log.csv: csv file found...  appending...

Please note that this code is fully linted and thus if you agree on this approach, I'll close #69 and create a new pull request.

@longstone
Copy link
Collaborator Author

@stynoo then I'll suggest going for the one with CSV storage, as it's ok with lint and also refactored.
The only thing there I'm not sure about is if it's a good idea to build a CSV database instead of storing a 'last_sync' timestamp for each target system in the configs JSON.

However, let's do it and discuss this tough there! Thanks for your effort 🙏

@stv0g stv0g changed the title Feature: Switching from saving lastUpdated on source, to saving lastUpdated on targets Switching from saving lastUpdated on source, to saving lastUpdated on targets Jun 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants