this might seem a very naive question but I am having a hard time to figure this out. I have a float value 37.50378 in my PostgreSQL database. When I am trying to fetch this value in my Nodejs application it gives me 37.5038. I want to fetch the exact number without rounding off the decimal digits. How do I do that?
The data type of the column in Postgres is Real.
EDIT
I am using Knex schema builder and using float(column, precision, scale) to create a column(to store above-said value). I have tried different numbers for precision and scale just in case that's causing the above-said behavior. But every time I tried to fetch the value 37.50378, all I get back is 37.5038.
Thanks.
You may want to use double(column) in knex, which is translated to double precision in postgres.
This is because of the real 4-byte precision. See PostgreSQL Numeric Types.
It's got nothing to do with Node.js or its PostgreSQL driver.
Related
Firestore can store 64 bit signed integers. However Javascript's number type has a 53 bit mantissa. How to read/write big numbers with Firestore without losing precision?
I tried:
Using BigInt: The Javascript SDK doesn't support it.
Using strings: This could do but I need sort operations for numbers.
For some reason the admin SDK has BigInt support, but the client library not.
Convert BigInt to a string and write it as a string to firestore. This modifies all clients you use to convert from string to BigInt and vice versa but will allow you to store large numbers as needed in the browser at least (due to JavaScript being 53 bit precision-ish). Not ideal but it works. If you need to query on that field in Firestore, I would then use a Cloud function to store the number in another field for querying. I realize this is not the ideal solution, but may help solve your issue in a pinch.
Finally, I would recommend doing is logging a feature request to the FireStore SDK for web to support BigInt.
I have read the official documentation about int64 and I need use NumberLong wrapper the int64. But I find there is some special values could be used without NumberLong:
In my image, I think the MongoDB Compass will treat 1128505640310804481 as double just like Javascript and use the round 1128505640310804500(this is what I get from Javascript). The data in DB is shown in int64 so I think the 1128505640310804481 is stored correctly as int64. Since 1128505640310804500 is not equal to 1128505640310804481, I think I should find no data matched my filter, but MongoDB Compass give me the result.
So my question is: when I enter int64 in MongoDB Compass Filter like the picture,
how does it deal with the int64 and why it could match the correct int64 data stored in DB?
when I enter int64 in MongoDB Compass Filter like the picture, how does it deal with the int64 and why it could match the correct int64 data stored in DB?
To start with, MongoDB can store 64-bit integer value because data are stored as BSON (binary serialisation format). This solves the issue in the server. See also BSON Types.
Now, for MongoDB Compass it is able to identify the type of number (int32, int64, or Double) by auto-casting. It detects the value in the editor, when an int32 is edited to a value over 32 bits AND the value passes the +/- of Number.isSafeInteger then it casts to int64.
Part of MongoDB Compass that does the type checking is actually has been open-sourced. See the type checker code: mongodb-js/hadron-type-checker/blob/master/src/type-checker.js. The NPM package is hadron-type-checker.
I have numbers generated from Javascript code and I want to store them in PostgreSQL table. I have legacy table where the whole JSON object is stored as JSONB type and in the new table I'd like to flatten the JSON to separate columns.
Ideally I want to avoid loss of precision as much as possible. Especially I'd like to avoid turning JS integer numbers into float numbers and vice versa. In other words inserting integer and getting back float is something I'd like to mitigate (if possible).
So far I've experimented with DOUBLE PRECISION and NUMERIC types. I think NUMERIC is better fit because documentation states that within the implementation limits there is no loss in precision. On the other hand DOUBLE PRECISION will be probably faster for numeric operations. I plan to do a lot of statistical operations.
I am not sure which one to choose. What is the optimal or recommended PostgreSQL data type with regards to maximum compatibility JavaScript Number type?
I am not JavaScript expert, but what I found on net, then JavaScript uses 64bit floats. It is same like DOUBLE PRECISION type - 8bytes like 8bytes.
I have a WCF service operation that returns an object with long and List<string> properties. When I test the operation in a WCF application, everything works fine and the values are correct. However, I need to be able to call the service using jQuery and JSON format. The value of the long property apparently changes when I read it back in the OnSucceed function.
After searching I've found that JSON.stringify changes big values. So in code like this:
alert(JSON.stringify(25001509088465005));
...it will show the value as 25001509088465004.
What is happening?
Demo here: http://jsfiddle.net/naveen/tPKw7/
JavaScript represents numbers using IEEE-754 double-precision (64 bit) format. As I understand it this gives you 53 bits precision, or fifteen to sixteen decimal digits. Your number has more digits than JavaScript can cope with, so you end up with an approximation.
Do you need to do maths operations on this big number? Because if its just some kind of ID you can return it as a string and avoid the problem.
The number is larger than 9223372036854775807 - too big for NumberLong, which is mongo's native 64-bit long type. What's the best way to do this/the best field type?
Is it possible to preserve any of the querying functionality of a smaller integer (such as {$lt})?
The big numbers are being generated by bignumber.js, and I'm using mongoose to interact with mongoDb.
I'm afraid that the only viable/safe option would be to store such big numbers as a string and serialize it back and forth between the application and MongoDB when read/written. However, you will loose the ability to use MongoDB built-in functions that work with numbers (you can still cast the values to numbers, but it won't be safe anymore).