Strange behavior with integer number literals being returned as objects {high: 23, low: 0}

[adrianseeley]

package: "neo4j-driver": "^1.1.0-M01"
node: v6.2.1

I'm creating a new node in Neo4J using the following from NodeJS, noting that the property 'datapoints' is a number literal:

CREATE (a:pipeline)
    SET a.uuid       = {uuid},
        a.type       = "datasource",
        a.datapoints = 0,
        a.normalized = {normalized},
        a.headers    = {headers},
        a.types      = {types},
        a.t_created  = {now}
RETURN a

Now when I go to lookup that node using the following statement I get different results from the Neo4J browser and NodeJS driver:

MATCH (a:pipeline)
RETURN a

If I run this statement from the Neo4J browser I get a response as expected where datapoints is indeed a number:

{
  "records": [
    {
      "keys": [
        "a"
      ],
      "length": 1,
      "_fields": [
        {
          "identity": "37225",
          "labels": [
            "pipeline"
          ],
          "properties": {
            "headers": [
              "dt",
              "h"
            ],
            "datapoints": "0",
            "types": [
              "Date",
              "Float"
            ],
            "normalized": false,
            "type": "datasource",
            "t_created": 1472143439959,
            "uuid": "1472143439959.562064"
          },
          "id": "37225"
        }
      ],
      "_fieldLookup": {
        "a": 0
      }
    }
  ],
  "summary": {
    "statement": {
      "text": "MATCH (a:pipeline)\nRETURN a",
      "parameters": {}
    },
    "statementType": "r",
    "updateStatistics": {
      "_stats": {
        "nodesCreated": 0,
        "nodesDeleted": 0,
        "relationshipsCreated": 0,
        "relationshipsDeleted": 0,
        "propertiesSet": 0,
        "labelsAdded": 0,
        "labelsRemoved": 0,
        "indexesAdded": 0,
        "indexesRemoved": 0,
        "constraintsAdded": 0,
        "constraintsRemoved": 0
      }
    },
    "plan": false,
    "profile": false,
    "notifications": []
  },
  "responseTime": 316
}

However when I run the same statement using the NodeJS package I get an unexpected object for datapoints:

{
   "records": [
      {
         "keys": [
            "a"
         ],
         "length": 1,
         "_fields": [
            {
               "identity": {
                  "low": 37225,
                  "high": 0
               },
               "labels": [
                  "pipeline"
               ],
               "properties": {
                  "headers": [
                     "dt",
                     "h"
                  ],
                  "datapoints": {
                     "low": 0,
                     "high": 0
                  },
                  "types": [
                     "Date",
                     "Float"
                  ],
                  "normalized": false,
                  "type": "datasource",
                  "t_created": 1472143439959,
                  "uuid": "1472143439959.562064"
               }
            }
         ],
         "_fieldLookup": {
            "a": 0
         }
      }
   ],
   "summary": {
      "statement": {
         "text": "MATCH (a:pipeline)\r\nRETURN a",
         "parameters": {}
      },
      "statementType": "r",
      "updateStatistics": {
         "_stats": {
            "nodesCreated": 0,
            "nodesDeleted": 0,
            "relationshipsCreated": 0,
            "relationshipsDeleted": 0,
            "propertiesSet": 0,
            "labelsAdded": 0,
            "labelsRemoved": 0,
            "indexesAdded": 0,
            "indexesRemoved": 0,
            "constraintsAdded": 0,
            "constraintsRemoved": 0
         }
      },
      "plan": false,
      "profile": false,
      "notifications": []
   }
}

The result seems to be same for setting the property's value to any integer literal value, however setting the property's value to a floating point literal value (other than 0.0) behaves as expected:

{
   "records": [
      {
         "keys": [
            "a"
         ],
         "length": 1,
         "_fields": [
            {
               "identity": {
                  "low": 37253,
                  "high": 0
               },
               "labels": [
                  "pipeline"
               ],
               "properties": {
                  "headers": [
                     "dt",
                     "h"
                  ],
                  "datapoints": 0.1,
                  "types": [
                     "Date",
                     "Float"
                  ],
                  "normalized": false,
                  "type": "datasource",
                  "t_created": 1472143956047,
                  "uuid": "1472143956047.414768"
               }
            }
         ],
         "_fieldLookup": {
            "a": 0
         }
      }
   ],
   "summary": {
      "statement": {
         "text": "MATCH (a:pipeline)\r\nRETURN a",
         "parameters": {}
      },
      "statementType": "r",
      "updateStatistics": {
         "_stats": {
            "nodesCreated": 0,
            "nodesDeleted": 0,
            "relationshipsCreated": 0,
            "relationshipsDeleted": 0,
            "propertiesSet": 0,
            "labelsAdded": 0,
            "labelsRemoved": 0,
            "indexesAdded": 0,
            "indexesRemoved": 0,
            "constraintsAdded": 0,
            "constraintsRemoved": 0
         }
      },
      "plan": false,
      "profile": false,
      "notifications": []
   }
}

I considered that it may be the name of my property that was causing the issue, and can add that any property name is currently having this effect. Is this maybe the result of a database corruption?

[brian-gates]

Take a look at https://github.com/neo4j/neo4j-javascript-driver#a-note-on-numbers-and-the-integer-type

[pontusmelke]

Yes it is as @brian-gates says. Neo4j uses 64 bit integers which is not natively supported in javascript. What is instead returned is an Integer.

[adrianseeley]

Thanks guys, the integer parsing function neoj4.v1.int(n).toNumber() did the trick, I suppose I overlooked this as I've been using integers everywhere without running into this problem - which must have been converted to floats somewhere before hitting the driver layer. Shouldn't integers by default be handled as small integers and only in extreme cases more code be required to handle larger integers?

[brian-gates]

Shouldn't integers by default be handled as small integers and only in extreme cases more code be required to handle larger integers?

IMO, no. Consistency is more important. Having some integers return differently than others is dangerous.

[adrianseeley]

I can agree that consistency is important, but what about a global setting useSmallIntegers?

[brian-gates]

useSmallIntegers seems like a useful configuration of a JavaScript specific driver.

FWIW, my lib cypher-stream (@1.0.0-alpha) wraps this library and exposes results as Node streams of native values.

[technige]

Converting integers to and from native numbers is a lossy operation. The Neo4j type system supports both 64-bit integers and 64-bit floats as basic types. The Number type in JS is technically a double, which maps directly to and from the latter but if we allow the same mapping for the former as well, we lose type information for both input and output values.

We are currently looking at how we might be able to improve the convenience of this aspect of the interface but for this reason we need to ensure that the type mappings are distinct and not lossy.

[oskarhane]

The interface have now changed with #153
Since the original question is solved and the discussion in this issue is sliding towards #106 I'll close this.

[lutovich]

Hi @adrianseeley, @brian-gates.

Please check #323 which makes it possible to create driver that only exposes native numbers.