-
Notifications
You must be signed in to change notification settings - Fork 55
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
[Config] Expose TTLDurationMapping as data module configuration #20
Conversation
import DataSourceStore from './data-source-store/dataSourceStore'; | ||
import { SubscriptionResponse } from '../data-sources/site-wise/types.d'; | ||
import { DataCache } from './data-cache/dataCacheWrapped'; | ||
import { Request } from './data-cache/requestTypes'; | ||
import { requestRange } from './data-cache/requestRange'; | ||
import { getDateRangesToRequest } from './data-cache/caching/caching'; | ||
import { viewportEndDate, viewportStartDate } from '../common/viewport'; | ||
import { MINUTE_IN_MS, SECOND_IN_MS } from '../common/time'; | ||
|
||
// given duration specified as a key, it may only be re-requested after the provided TTL value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll move this (and more) into doc-site documentation once we align on an approach.
/** | ||
* Create a new data module, optionally with a pre-hydrated data cache. | ||
* | ||
*/ | ||
constructor(initialDataCache?: DataStreamsStore) { | ||
constructor(configuration: IotAppKitDataModuleConfiguration = {}) { | ||
const { initialDataCache, ttlDurationMapping = DEFAULT_TTL_DURATION_MAPPING } = configuration; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about having ttlDurationMapping
be even more granular and attached to a DataStreamStore
but I think that's overkill for now. Especially because other time-series offerings like Grafana don't even offer this type of granular customization.
If we want to add granularity per stream in the future it should be fairly straightforward - more specific configuration will simply override this data module scoped configuration.
24681ab
to
19a7dd5
Compare
@@ -506,6 +508,87 @@ describe('caching', () => { | |||
}); | |||
}); | |||
|
|||
describe('cache settings', () => { | |||
let getDateRangesToRequestSpy = jest.spyOn(caching, 'getDateRangesToRequest'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can be const
?
Allow entering entity id with autosuggest Co-authored-by: Zuraiz Zafar 🙃 <zuraiz@amazon.com>
Overview
The IoT App Kit takes a granular approach to time-series caching rules. The idea is to allow data points to be re-requested at different frequencies depending on how close those data points are to chart boundaries - e.g. more "recent" data can be refreshed with higher frequency.
This change allows IoT App Kit consumers to customize cache invalidation rules by overriding the default
ttlDurationMapping
.Tests
https://github.com/boweihan/iot-app-kit/runs/4523021422?check_suite_focus=true
Legal
This project is available under the Apache 2.0 License.