I am using Neo4j Community 4.0.4.
Trying to set a parameter name in the Neo4j Browser, in accordance with the help topic:
:param doc_name => '...'
Getting the following error, though:
Syntax error at line 1 col 4:
doc_name => ...'
^
Unexpected "_".
I know that the parameter names with underscores in them are allowed by the engine, because I am using them in driver sessions... Why would they be not allowed in the Browser and what is the way to fix it?
The issue is not the browser rather in what's enforcing the Cypher rules. While an underscore works fine in names (I pref camel), for parameters, it's stated as follows in 2.6 of the Cypher docs:
"Parameters may consist of letters and numbers, and any combination of these, but cannot start with a number or a currency symbol."
I do wish the authors were a lot more specific, as this "interesting" delta between variable names and parameter names should be clearer and called out, I take this as "no non-alpha-numeric chars". Because I avoid underscores for lots of reasons (did you know there's a few types of underscores which can cause some hair-pulling debugging sessions ), I did just test and prove that params and param play by those rules.
So not sure what context you mean for the "driver sessions", but based on the Cypher rules, this is the language and not the browser and working as designed.
For instance, I am using the parameter $doc_name and can substitute it with no issues when using the driver().session().run() method of the officially supported Python Bolt driver to run a Cypher statement.
Setting the SAME parameter before running the same statement in the Neo4j Browser (e. g. during query development and debugging) using the :param command causes the error that I quoted in my original post.
This puzzles me... If the Pythonic variable naming convention of only lowercase letters, numbers and underscores (ASCII code 95) is not allowed for some reason, I can live with that, but it would be nice to know for sure.... The statement from the Cypher docs that you kindly quoted is controversial - it does not mention special characters in the first (permissive) part, but implies that they may be used not at the start of the string.
I think you've shouted out what should become more and more of a real concern in the goal of graph adoption: consistency in all the ways we interact with the graph. E.g.,: why quotes on one direction and no quote on the opposite; why part of my communication with Neo4j's DB allows something (like "_") ...but not always [your concern]; what's the real impact/function of the comma in a Cypher query; etc.
"Elegance" is my favorite term in English because it means: "beauty that shows unusual effectiveness and simplicity". Build elegant solutions is not about the aesthetic, rather the ability to create enjoyable habits that quickly become intuitive. Unfortunately, engineers test solutions 500+ times until we're ready to ship thus creating very little understanding of real-world use cases.
In short, I think we're in an opportunistic time for graphs and their adoption. Meaning, things will be immature for a while and we'll need folks like you to call out use cases like yours (and you're not alone BTW!).
We're all "early adopters" at this point in the graph community - which is our opportunity to learn what changes are needed in order to speak clearly to the upcoming pragmatists so they jump onboard