cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.

Support of type Long in Cypher queries

Consulting the Neo4j cypher documentation and performing some tests show that it is only possible to use type Integer (and Float) for numbers in Cypher queries. There is no way to store a Long value as property.
E.g. the query
create (n:Person {id:'Me', myLong:15165169950000000000})
returns the error
Neo.ClientError.Statement.SyntaxError: integer is too large (line 1, column 35 (offset: 34))
Also trying to set a long value on an existing node produces the same error. I used the version 3.3.2.
Will there be the possibility in future to be able to use Longs in queries, or is there a workaround that I may use?
Thanks in advance.

1 ACCEPTED SOLUTION

The Cypher Integer is the same as the java long, which has a maximum value of 9,223,372,036,854,775,807. The number you used is 15,165,169,950,000,000,000 which is larger than the largest possible long. If you only need to store long values, then Cypher is fine for you. If you need to store larger values, then you need to store them in some other way, either convert to strings and store as a String, or store as two longs (high and low), or serialize to a byte[] and store that.

View solution in original post

7 REPLIES 7

The Cypher Integer is the same as the java long, which has a maximum value of 9,223,372,036,854,775,807. The number you used is 15,165,169,950,000,000,000 which is larger than the largest possible long. If you only need to store long values, then Cypher is fine for you. If you need to store larger values, then you need to store them in some other way, either convert to strings and store as a String, or store as two longs (high and low), or serialize to a byte[] and store that.

Thank you very much for your help. I have overlooked, that the value I used is greater than MAX_LONG. So long values are fine for me.

I think there is a bug in the Neo4J version 4.1 while dealing with Long data types. I tried inserting below statement in Version 4.1 and Version 3.5,

Neo4J 4.1

MERGE (POINT: TEST1 {myRandomValue: 1594633221523})

Outcome:
{
"identity": 251,
"labels": [
"TEST1"
],
"properties": {
"myRandomValue": 1200354707
}
}

While Executing same statement in Neo4J 3.5

MERGE (POINT: TEST1 {myRandomValue: 1594633221523})

Outcome:
{
"identity": 251,
"labels": [
"TEST1"
],
"properties": {
"myRandomValue": 1594633221523
}
}

So in Neo4J 4.1 Long value is losing the precision and this is a major problem.

Regards,
Maulik

Please convert the integer to String using inbuilt functions and see if error goes away.When you query the data you can use following java
Long. parseLong( String ).

I believe this is only if you are using the Javascript driver to talk to Neo4j. It is a limitation in Javascript that was hidden in Neo4j 3.5 due to another bug in server-side type handling, which was fixed in Neo4j 4.0. The correct solution is to use the Neo4j Javascript libraries int() function to convert the number to a type that will be correctly understood on the server side.

See https://neo4j.com/docs/api/javascript-driver/current/class/src/integer.js~Integer.html

The Javascript issue is that the language does not support integers at all, and they are instead sent as floating point values. The bug on the server side was that Neo4j was silently coercing floats to ints for some cases, which actually hides other problems and needed to be fixed.

@craig.taverner I just ran

Might that bug still exist in 4.x? The following numbers should NOT equal one another, but neo4j thinks they do. (code was run in neo4j v4.2, first via the browser interface and then using the python driver):

RETURN 2^63-2 AS Minus2, 2^63-1 AS Minus1, 2^63-2 = 2^63-1 AS Comparison
╒════════════════════════╤═════════════════════╤═════════════╕
│"Minus2"              │"Minus1"           │"Comparison"│
╞════════════════════════╪═════════════════════╪═════════════╡
│9223372036854776000.0 │9223372036854776000.0│true      │
└────────────────────────┴─────────────────────┴─────────────┘

But, if I wrap the big numbers in a toInteger() statement, Cypher reads them correctly:

RETURN toInteger(2^63)-2 AS Minus2, toInteger(2^63)-1 AS Minus1, toInteger(2^63)-2 = toInteger(2^63)-1 AS Comparison
╒════════════════════════╤═════════════════════╤═════════════╕
│"Minus2"              │"Minus1"           │"Comparison"│
╞════════════════════════╪═════════════════════╪═════════════╡
│9223372036854775805   │9223372036854775806│true        │
└────────────────────────┴─────────────────────┴─────────────┘

@B-D-T

might be an issue with the representation via the driver. for example with neo4j 4.3.3 and cypher-shell, which uses the Neo4j Java driver

neo4j@neo4j-lg:~/single/instance1/neo4j-enterprise-4.3.3/bin$ ./cypher-shell
Connected to Neo4j using Bolt protocol version 4.1 at neo4j://localhost:7687.
Type :help for a list of available commands or :exit to exit the shell.
Note that Cypher queries must end with a semicolon.
@graph.db> RETURN 2^63-2 AS Minus2, 2^63-1 AS Minus1, 2^63-2 = 2^63-1 AS Comparison;
+----------------------------------------------------------+
| Minus2               | Minus1               | Comparison |
+----------------------------------------------------------+
| 9.223372036854776E18 | 9.223372036854776E18 | TRUE       |
+----------------------------------------------------------+

1 row
ready to start consuming query after 1109 ms, results consumed after another 2 ms
@graph.db> RETURN toInteger(2^63)-2 AS Minus2, toInteger(2^63)-1 AS Minus1, toInteger(2^63)-2 = toInteger(2^63)-1 AS Comparison
           ;
+--------------------------------------------------------+
| Minus2              | Minus1              | Comparison |
+--------------------------------------------------------+
| 9223372036854775805 | 9223372036854775806 | FALSE      |
+--------------------------------------------------------+

1 row
ready to start consuming query after 404 ms, results consumed after another 30 ms