-
Notifications
You must be signed in to change notification settings - Fork 180
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
BigInt returned as string #403
Comments
I use loopback 4 and I have the same problem with Here's an extract of my model : @model()
export class MyModel extends Entity {
@property({
type: 'number',
required: true,
postgresql: {
dataType: 'decimal'
}
})
my_prop: Number;
} I tried to trace a |
I suspect the following line may be the culprit: As per lb docs, |
So I did some digging, turns out :
To fix this issue, you need to provide a parser for the targeted type. In my case I did the following : import {types} from 'pg'
// 1700 : Numeric (https://github.com/brianc/node-pg-types/blob/master/index.d.ts#L42)
types.setTypeParser(1700, parseFloat) @vikramkh For your BigInt case, the fix should be |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the |
As this issue is being closed, maybe the use of pg |
@QuentinLB , the solution you mention above seems to involve only node.js and the |
Hi @emonddr I have no idea how it integrate with LB3, I stumbled on this issue while working on a LB4 server. What I can describe was my assumption working on my server that use this connector. Once my models defined I was surprised to see my non-string models properties being returned as string (see my previous example). As a way to avoid getting this type of issue open again I was suggesting to document the fact that neither LB nor this connector handle this behavior, allow the user facing this issue to setup their own Another way to manage this would be to setup those type parser in initializeDataSource but I'm not sure if it's the best place or the responsibility of the connector to do this. Finally maybe it's the responsibility of node-pg-types to change this behavior since it was added at a time Node didn't have proper 64bit numeric types. There's an issue open on their repo addressing this brianc/node-pg-types#78 Hope that helps |
@QuentinLB , sorry, I meant LB4. |
My bad |
@QuentinLB , where exactly does this code go?
In a file in the node_modules or in each of the individual repositories? I'm really confused sorry |
It doesn't matter where you setup your types parsers since it's a static interface. What matter is when you do this setup. If you use Loopback, I recommend to do it during the application initialization ; this way you ensure that your parser are setup before any connection to the database and before migrations. |
@QuentinLB Thanks again for the help. After adding:
I get the error:
I am using node v10.15.3 |
You can't use BigInt.prototype.toJSON = function() { return this.toString() } However by my understanding of your issue, trying to serialize your data seems convoluted. By default node-pg return already everything as string, so if you try to serialize it afterwards no need to set a type parser. I think you should also look into the necessity to use BigInt, given the support for BigInt in js. If you use BigInt for an id, you should handle it as a string in you code since you won't use it as a number. Even better, use auto-generated uuids. |
Steps to reproduce
I have two models, Players and Team. Both ids are BigInts. Players has a foreign Key teamId which is of type BigInt in the database, and number in Postgres model properties.
Current Behavior
When I do .find() on players, teamId is returned as a string. If I do .execute, both id and teamId are returned as a string.
Expected Behavior
When I do .find(), or .execute, both id and teamId should be returned as numbers (or both as strings for consistencies sake)
Additional information
The text was updated successfully, but these errors were encountered: