By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In Neo4j 2.3.3, this query runs well:

["MATCH (n) WHERE {props} RETURN n" {:props {"name" "Bob Smith" "age" 42 "city" "Brooklyn, New York"}}]

but this query throws a "Parameter maps cannot be used in MATCH patterns (use a literal map instead, eg. "{id: {param}.id}" exception, and returns with a status 400:

["MATCH (n {props}) RETURN n" {:props {"name" "Bob Smith" "age" 42 "city" "Brooklyn, New York"}}]

It seems like these two queries essentially do the same thing. For consistency, could Cypher allow the second, as well as the first? I know that not explicitly naming the properties might make execution plan caching less efficient. But what I wound up doing (before I realized that the first query worked fine) was writing my own functions to convert from this:

{"name" "Bob Smith" "age" 42 "city" "Brooklyn, New York"}

to this:

["MATCH (n { name:{name}, age:{age}, city:{city} })" {:name "Bob Smith" :age 42 :city "Brooklyn, New York"}]

by concatenating together little bits of strings, which I think is just as inefficient, and also much more prone to bugs. Thanks.

Relevant StackOverflow threads:

http://stackoverflow.com/questions/24211261/can-i-parameterize-labels-and-properties-on-create-or-set-rest-and-transaction
http://stackoverflow.com/questions/28716699/parameter-maps-cannot-be-used-in-merge-patterns
http://stackoverflow.com/questions/27094532/java-neo4j-cypher-query-to-match-node

Relevant previous issue, #1525

Not using a label makes it way more inefficient. :)

Yes it is for planning reasons

Your first query does not do what you think

It tests if the property value is non-false

Von meinem iPhone gesendet

Am 23.04.2016 um 12:30 schrieb rationalism notifications@github.com :

In Neo4j 2.3.3, this query runs well:

["MATCH (n) WHERE {props} RETURN n" {:props {"name" "Bob Smith" "age" 42 "city" "Brooklyn, New York"}}]

but this query throws a "Parameter maps cannot be used in MATCH patterns (use a literal map instead, eg. "{id: {param}.id}" exception, and returns with a status 400:

["MATCH (n {props}) RETURN n" {:props {"name" "Bob Smith" "age" 42 "city" "Brooklyn, New York"}}]

It seems like these two queries essentially do the same thing. For consistency, could Cypher allow the second, as well as the first? I know that not explicitly naming the properties might make execution plan caching less efficient. But what I wound up doing (before I realized that the first query worked fine) was writing my own function to convert from this:

{"name" "Bob Smith" "age" 42 "city" "Brooklyn, New York"}

to this:

MATCH (n { name:'Bob Smith', age:42, city:'Brooklyn, New York' })

by concatenating together little bits of strings, which I think is just as inefficient, and also much more prone to bugs. Thanks.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

Oh! Good catch there. Darn. I guess I have to go back to string concatenation. Thanks a lot for letting me know.

These aren't real queries (all my real queries use labels), just test queries I'd created for illustration.