Stringified numbers in Node labels result in syntax errors

[daniel-j-h]

Even though the Node constructor accepts str objects for node labels, it looks like for some reason stringified numbers result in syntax errors.

Reproducible with

docker run -p 6379:6379 -it --rm redislabs/redisgraph:1.0.15

and redisgraph==1.7 from pip

from redis import Redis
from redisgraph import Node, Edge, Graph

r = Redis()
g = Graph("test", r)

g.add_node(Node(label="123"))

g.commit()

results in

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/daniel/py/cosmos/.env/lib/python3.6/site-packages/redisgraph/client.py", line 136, in commit
    return self.query(query)
  File "/home/daniel/py/cosmos/.env/lib/python3.6/site-packages/redisgraph/client.py", line 155, in query
    response = self.redis_con.execute_command("GRAPH.QUERY", self.name, q)
  File "/home/daniel/py/cosmos/.env/lib/python3.6/site-packages/redis/client.py", line 775, in execute_command
    return self.parse_response(connection, command_name, **options)
  File "/home/daniel/py/cosmos/.env/lib/python3.6/site-packages/redis/client.py", line 789, in parse_response
    response = connection.read_response()
  File "/home/daniel/py/cosmos/.env/lib/python3.6/site-packages/redis/connection.py", line 642, in read_response
    raise response
redis.exceptions.ResponseError: Syntax error at offset 23 near '123'

The workaround is to use character pre- and post-fixed labels such as a-123-b. Ugly but works. This looks like a parser / syntax problem.

Where can I find details on what is allowed and what is not currently? Should the Python client warn or even assert before users run into this? It's pretty hard to debug on the user's side.

[swilly22]

@daniel-j-h correct, this is indeed a syntax error, labels are specified as unquoted strings.

[daniel-j-h]

Is there a reference for the allowed syntax somewhere?

Should the client check the label conforming to the allowed syntax?

[swilly22]

https://neo4j.com/docs/cypher-manual/current/syntax/naming/ I think a syntax error is sufficient in this case.