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

Return API v1 entries through API v3 history API #8244

Open
mrinnetmaki opened this issue Mar 24, 2024 · 0 comments
Open

Return API v1 entries through API v3 history API #8244

mrinnetmaki opened this issue Mar 24, 2024 · 0 comments

Comments

@mrinnetmaki
Copy link

mrinnetmaki commented Mar 24, 2024

Is your feature request related to a problem? Please describe.
I'm building a tool that periodically polls the Nightcout server and copies data to another location. I'd like to use the v3 API for that.

Currently entries written through the v1 API (in my case, with xDrip+) are not included in the result set when using v3 API call /api/v3/entries/history/1001720530000.

I've tracked this and believe it is because the history API expects the srvModified field to be populated for all entries in the database. But they are not populated for entries stored with the v1 API.

Describe the solution you'd like
I'd like to see entries written through the v1 API be included in the results returned by the v3 history API.

Describe alternatives you've considered
Potential solutions I can think of are:

  1. Expect all apps to start using the v3 API. Would be nice, but is somewhat out of reach. Also in this case, I believe the documents already in the database should be post-processed to include the srvModified field (or alternatively have fancy logic for using date and created_at fields when srvModified is not present.

  2. Modify the v1 API to automatically populate the srvModified field for any stored documents. There is a risk that this would affect some clients out there, but I don't think it actually breaks any API contracts. Like the option above, this would also need existing documents be post-processed.

  3. Make the history API search include also results that are stored with the v1 API. I.e., use fields date and created_at when the field srvModified is not present in the document. This would not be bullet-proof, as clients do store older data.

Additional context
I can also use the v1 API to do the syncing. There my current issue is to find the oldest stored document for each of the collections (or the oldest one overall). Is there a way to get that through an API call?

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

1 participant