Bigint's returning as string (Postgres)

516 views
Skip to first unread message

Nolan Dubeau

unread,
Nov 5, 2014, 3:36:20 PM11/5/14
to loopb...@googlegroups.com
Hi,

I have noticed some strange behaviour in some of our data models.

We have a Customer Model which has the following numeric properties:

id:  bigint
branding_id: integer
reseller_id: bigint

When querying for a Customer the following is returned:

{
  • id1,
  • resellerId"1",
  • customerName"ACME Corp",
  • addressIdnull,
  • created"2010-07-01T06:41:38.000Z",
  • modified"2010-07-01T06:41:38.000Z",
  • approved"2012-10-24T21:37:04.067Z",
  • activetrue,
  • brandingId1,
  • measurement"Imperial",
  • eulanull
}

Despite the id and resellerID's being the same datatype in the database (biging), one comes back as numeric and the other comes back as string.  Also, brandingID defined as an integer in the db returns as a numeric whereas resellerID returns as strings?

This is really frustrating.  Can you please explain this behaviour?  Is it something related to our model definition?  Here are the three field definitions:
"id": {
      "type": "Number",
      "id": true,
      "required": true,
      "index": true,
      "length": null,
      "precision": 64,
      "scale": 0,
      "postgresql": {
        "columnName": "id",
        "dataType": "bigint",
        "dataLength": null,
        "dataPrecision": 64,
        "dataScale": 0,
        "nullable": "NO"
      }
    },
 "resellerId": {
      "type": "Number",
      "required": false,
      "length": null,
      "precision": 32,
      "scale": 0,
      "postgresql": {
        "columnName": "reseller_id",
        "dataType": "bigint",
        "dataLength": null,
        "dataPrecision": 32,
        "dataScale": 0,
        "nullable": "YES"
      }
    },
"brandingId": {
      "type": "Number",
      "required": false,
      "length": null,
      "precision": 32,
      "scale": 0,
      "postgresql": {
        "columnName": "branding_id",
        "dataType": "integer",
        "dataLength": null,
        "dataPrecision": 32,
        "dataScale": 0,
        "nullable": "YES"
      }
    }

Any help on this is greatly appreciated.
Thank you.

Raymond Feng

unread,
Nov 5, 2014, 4:57:07 PM11/5/14
to Nolan Dubeau, loopb...@googlegroups.com
Do you have relations with foreign key defined?

Thanks,

---
Raymond Feng
Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop makes it easy to develop APIs in Node, plus get DevOps capabilities like monitoring, debugging and clustering.

--
You received this message because you are subscribed to the Google Groups "LoopbackJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loopbackjs+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nolan Dubeau

unread,
Nov 5, 2014, 10:34:15 PM11/5/14
to Raymond Feng, loopb...@googlegroups.com
Yes,  branding_id and reseller_id are both relations.

Raymond Feng

unread,
Nov 6, 2014, 12:45:04 AM11/6/14
to Nolan Dubeau, loopb...@googlegroups.com
The type of a foreign key will be overridden by the primary. What are the types of our branding id and reseller id?

Thanks,

---
Raymond Feng
Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop makes it easy to develop APIs in Node, plus get DevOps capabilities like monitoring, debugging and clustering.

Nolan Dubeau

unread,
Nov 6, 2014, 12:42:03 PM11/6/14
to loopb...@googlegroups.com
Here is the model:

{
  "name": "Customer",
  "idInjection": false,
  "postgresql": {
    "schema": "public",
    "table": "customer"
  },
  "properties": {
    "id": {
      "type": "Number",
      "id": true,
      "required": true,
      "index": true,
      "length": null,
      "precision": 64,
      "scale": 0,
      "postgresql": {
        "columnName": "id",
        "dataType": "bigint",
        "dataLength": null,
        "dataPrecision": 64,
        "dataScale": 0,
        "nullable": "NO"
      }
    },
     "resellerId": {
      "type": "Number",
      "required": false,
      "length": null,
      "precision": 32,
      "scale": 0,
      "postgresql": {
        "columnName": "reseller_id",
        "dataType": "integer",
        "dataLength": null,
        "dataPrecision": 32,
        "dataScale": 0,
        "nullable": "YES"
      }
    },
    "customerName": {
      "type": "number",
      "required": true,
      "length": 75,
      "precision": null,
      "scale": null,
      "postgresql": {
        "columnName": "customer_name",
        "dataType": "character varying",
        "dataLength": 75,
        "dataPrecision": null,
        "dataScale": null,
        "nullable": "NO"
      }
    },
    "addressId": {
      "type": "Number",
      "required": false,
      "length": null,
      "precision": 32,
      "scale": 0,
      "postgresql": {
        "columnName": "address_id",
        "dataType": "integer",
        "dataLength": null,
        "dataPrecision": 32,
        "dataScale": 0,
        "nullable": "YES"
      }
    },
    "created": {
      "type": "string",
      "required": false,
      "length": null,
      "precision": null,
      "scale": null,
      "postgresql": {
        "columnName": "created",
        "dataType": "timestamp without time zone",
        "dataLength": null,
        "dataPrecision": null,
        "dataScale": null,
        "nullable": "NO"
      }
    },
    "modified": {
      "type": "date",
      "required": false,
      "length": null,
      "precision": null,
      "scale": null,
      "postgresql": {
        "columnName": "modified",
        "dataType": "timestamp without time zone",
        "dataLength": null,
        "dataPrecision": null,
        "dataScale": null,
        "nullable": "NO"
      }
    },
    "active": {
      "type": "Boolean",
      "required": false,
      "length": null,
      "precision": null,
      "scale": null,
      "postgresql": {
        "columnName": "active",
        "dataType": "boolean",
        "dataLength": null,
        "dataPrecision": null,
        "dataScale": null,
        "nullable": "NO"
      }
    },
    "brandingId": {
      "type": "Number",
      "required": false,
      "length": null,
      "precision": 32,
      "scale": 0,
      "postgresql": {
        "columnName": "branding_id",
        "dataType": "integer",
        "dataLength": null,
        "dataPrecision": 32,
        "dataScale": 0,
        "nullable": "YES"
      }
    }
  },
  "validations": [],
  "relations": {
    "users": {
      "type": "hasMany",
      "model": "User",
      "foreignKey": "customerId"
    }
  },
  "acls": [],
  "methods": []
}


I'm in the process of setting up the relations for branding_id and reseller_id.  These relations are a one-to-one relation from Customer to Branding and Reseller actually points back to Customer.  How would I construct the relation for these?  Would it be a belongsTo?

"relations": {
    "branding": {
      "type": "belongsTo",
      "model": "Branding",
      "foreignKey": "??????"
    }
  }

Thanks.

Nolan

Raymond Feng

unread,
Nov 6, 2014, 2:04:32 PM11/6/14
to Nolan Dubeau, loopb...@googlegroups.com
1. I see you have Customer has many users. Can you elaborate?

2. Customer belongsTo Branding

3. What model represents Reseller?

For belongsTo, the foreign key is defined on the source model. For hasOne/hasMany, the foreign key is defined on the target model.

Thanks,

---
Raymond Feng
Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop makes it easy to develop APIs in Node, plus get DevOps capabilities like monitoring, debugging and clustering.

Serkan Serttop

unread,
Nov 27, 2014, 4:19:48 AM11/27/14
to loopb...@googlegroups.com, nolan...@gmail.com
Raymond,
I understand that the error in question seems to be the inconsistent behavior, which I have not tested so I can't comment on that.
The title of the question seems to suggest that it is wrong when the json returns BIGINTs as strings.
I remember from using the Twitter API that they also provide "id_str" field as BIGINTs can be greater than the JS numeric data type's range.
For that reason I think json should return strings for BIGINTs.
I looked at MySQL and PostgreSQL connector docs, MySQL does not have BIGINT listed, for PG BIGINT is converted as Number for Loopback.
Could you clarify this point as well?

Felipe Figueroa

unread,
Nov 28, 2014, 8:35:50 PM11/28/14
to loopb...@googlegroups.com, nolan...@gmail.com
javascript can't handle 64 bit integers. So if you have a field defined as BIGINT, it depends on how many effective digits are you using. 

There are workarounds. For example, Mongoose has mongoose-long extension that stores a Bigint as an object.
Reply all
Reply to author
Forward
0 new messages