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

Estimate value sizes for Deno KV #19007

Open
kitsonk opened this issue May 6, 2023 · 0 comments
Open

Estimate value sizes for Deno KV #19007

kitsonk opened this issue May 6, 2023 · 0 comments
Labels
public API related to "Deno" namespace in JS suggestion suggestions for new features (yet to be agreed)

Comments

@kitsonk
Copy link
Contributor

kitsonk commented May 6, 2023

Related #18415, #12379

Deno KV currently has a value limit of 64KiB. While determining the size of things like strings and array buffers are straight forward, serialized objects are not straight forward. Especially things like Map() and Set() which may have deeply nested complex objects. Attempting the store the value and managing exceptions doesn't feel like a logical way to manage it. A user would want to know if a potential value is too big to store, potentially breaking it down and storing it as sub keys of an additional key. Like for example if an instance of a Map() is too big, recursively iterate over the keys, and store each key individually once it was "small enough".

A straight forward API that allows sizing of a value to be stored. While Deno.core.serialize() is available, it rightfully so isn't a public API, and even then it would be wasteful to allocate the ArrayBuffer in memory, only to get its size and discard it, likely to store it in the database.

@aapoalas aapoalas added public API related to "Deno" namespace in JS suggestion suggestions for new features (yet to be agreed) labels May 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
public API related to "Deno" namespace in JS suggestion suggestions for new features (yet to be agreed)
Projects
None yet
Development

No branches or pull requests

2 participants