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

Avoid conversion while getting values #3

Open
Shqrp opened this issue May 22, 2021 · 4 comments
Open

Avoid conversion while getting values #3

Shqrp opened this issue May 22, 2021 · 4 comments

Comments

@Shqrp
Copy link

Shqrp commented May 22, 2021

Hello! I'm currently using this version of quick.db and there is a problem when getting values: for example I have the ID 842846562882813982 set to the key logchannel. Whenever I set it, it's all fine, but whenever I try and get the value it just gets converted to a number, and because of the JSON.parse precision limit it returns 842846562882814000. Looking at the source code, it looks like this is a problem also for normal quick.db. So I'm asking if the conversion can be avoided in any way.

EDIT: forgot to tell that json-bigint can be used as a substitute for the built-in JSON namespace.

@zyrouge
Copy link
Member

zyrouge commented May 29, 2021

You shouldn't be using such long numbers imo. Save as string and use it.

@Shqrp
Copy link
Author

Shqrp commented May 31, 2021

The problem is that whenever I try to save it, it saves as string. But whenever I get it, it converts to number.

@Shqrp
Copy link
Author

Shqrp commented May 31, 2021

I think I may have found a solution: just add a string of characters before the ID and it will get picked as a string overall. But this should be a temporary solution, it can't be like this. So if it's possible to save IDs as keys/values that would be amazing.

@zyrouge
Copy link
Member

zyrouge commented Jun 2, 2021

I doubt https://github.com/DevSnowflake/quick.db/blob/0aee816124a8ab99f8e3964ef8046076bebe4c12/src/Database.js#L137 line as the cause of parsing it twice (stringified data -> parsed data (string) -> parsed again (number)). Definitely needs to be fixed imo.

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