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

Cache forecast with ttl #2

Merged
merged 2 commits into from
Apr 1, 2024
Merged

Cache forecast with ttl #2

merged 2 commits into from
Apr 1, 2024

Conversation

ciaarraa
Copy link
Owner

@ciaarraa ciaarraa commented Apr 1, 2024

Why?
Each request to yr.no comes with an expiry time. We should not ask for
the same forecast again if the first one is not expired.

How?
Extend the cache package to use PutWithTTL to the database. This will
save an object. When we ask to retrieve that object, if it is expired
it will throw a KeyExpired error. We should then call the yr.no api

In order to allow this to happen, we need to change the cache
implementation to pass through the errors which are returned from
bitcask.

CiaraTully added 2 commits April 1, 2024 17:01
Why?
Each request to yr.no comes with an expiry time. We should not ask for
the same forecast again if the first one is not expired.

How?
Extend the cache package to use PutWithTTL to the database. This will
save an object. When we ask to retrieve that object, if it is expired
it will throw a KeyExpired error.

In order to allow this to happen, we need to change the cache
implementation to pass through the errors which are returned from
bitcask.

Currently all of the logic is inside the command function. Ideally, this
could be split out into a package.
@ciaarraa ciaarraa merged commit 0f3da19 into main Apr 1, 2024
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

Successfully merging this pull request may close these issues.

1 participant