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

Suggestion for potential addition for better storage management. #9

Open
NamanShergill opened this issue Mar 19, 2021 · 4 comments
Open

Comments

@NamanShergill
Copy link

NamanShergill commented Mar 19, 2021

Idea 1:
Maybe an option to specify the max amount of items (or size) the cache stores at a time, in the interceptor, Currently it seems like the package caches everything and never deletes them (even in the case mentioned below), unless a new response overwrites it, which could lead to uncomfortable cache sizes for some apps.

Idea 2:
Delete the data from cache if it comes up as expired when checked.

Whoops sorry, wrote this while half asleep, confused maxAge and maxStale.

@NamanShergill
Copy link
Author

I'm still going through the code so I apologise if I missed and mentioned something the package already does!

@NamanShergill NamanShergill changed the title Suggestions for potential additions for better storage management. Suggestion for potential addition for better storage management. Mar 19, 2021
@llfbandit
Copy link
Owner

You're right there's nothing to implictly delete old cached values against a given limit.
There's no access time set to the values to handle this.

As I use this package for one my project, I'm not too worried by the data size. I store many quite big JSON entities for a year period and the database is sized around 3-4MB when fully populated.

FYI, this package is designed for small / medium data, not to store images and so on like we can do when navigating on web browsers.

Despite this, each store calls clean(staleOnly: true) to remove values with maxStale when instanciated which not cover your proposal.

This is a good suggestion. I'll think about this.

@NamanShergill
Copy link
Author

NamanShergill commented Mar 19, 2021

You're right there's nothing to implictly delete old cached values against a given limit.
There's no access time set to the values to handle this.

As I use this package for one my project, I'm not too worried by the data size. I store many quite big JSON entities for a year period and the database is sized around 3-4MB when fully populated.

FYI, this package is designed for small / medium data, not to store images and so on like we can do when navigating on web browsers.

Ah, I did not know it actually took only that much space!

Despite this, each store calls clean(staleOnly: true) to remove values with maxStale when instanciated which not cover your proposal.

This is a good suggestion. I'll think about this.

Oh, so basically all stale values are deleted? I thought it was only done for a specific entry when it was checked and it turned out to be stale. I did feel I must've missed something in the code.

There's no access time set to the values to handle this.

Makes sense. Plus if the package purges all stale data by itself anyway I guess it will always stay a manageable size in most cases, as you mentioned.

@llfbandit
Copy link
Owner

Re-opening, this is still a valid request.

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

2 participants