Hi! Looks like the app is querying for CGM data using queries such as:
/api/v1/entries?find%5Bdate%5D%5B$gt%5D=1599277060032.0&find%5Bdate%5D%5B$lte%5D=1599339600000.0&count=400
and issuing these fairly frequently. I'm getting reports that Atlas users are hitting database query limits when using Nightscout apps that hit the database frequently. If feasible, please consider refactoring the app in a way where instead of reloading historic data very frequently, only poll for the latest readings with most queries. If you query for /api/v1/entries.json?count=144, this would give you 12 hours of data for most NS users and should be enough to keep the local data up to date. We're working on adding in-memory caching to NS for the next release, and this query will subsequently not hit the database at all, while the queries that use date queries will continue to load the database.
Hi! Looks like the app is querying for CGM data using queries such as:
/api/v1/entries?find%5Bdate%5D%5B$gt%5D=1599277060032.0&find%5Bdate%5D%5B$lte%5D=1599339600000.0&count=400
and issuing these fairly frequently. I'm getting reports that Atlas users are hitting database query limits when using Nightscout apps that hit the database frequently. If feasible, please consider refactoring the app in a way where instead of reloading historic data very frequently, only poll for the latest readings with most queries. If you query for /api/v1/entries.json?count=144, this would give you 12 hours of data for most NS users and should be enough to keep the local data up to date. We're working on adding in-memory caching to NS for the next release, and this query will subsequently not hit the database at all, while the queries that use date queries will continue to load the database.