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?
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
srvModifiedfield 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
srvModifiedfield (or alternatively have fancy logic for usingdateandcreated_atfields whensrvModifiedis not present.2) Modify the v1 API to automatically populate the
srvModifiedfield 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
dateandcreated_atwhen the fieldsrvModifiedis 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?