From 1757f71883649d18730e9f245e0b84ba95f3a884 Mon Sep 17 00:00:00 2001 From: Pontus Melke Date: Mon, 12 Oct 2015 11:11:30 +0200 Subject: [PATCH 1/7] first draft of CREATE CIP --- cip/CIP-2015-10-12-CREATE.adoc | 131 +++++++++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 cip/CIP-2015-10-12-CREATE.adoc diff --git a/cip/CIP-2015-10-12-CREATE.adoc b/cip/CIP-2015-10-12-CREATE.adoc new file mode 100644 index 0000000000..96e36fe44e --- /dev/null +++ b/cip/CIP-2015-10-12-CREATE.adoc @@ -0,0 +1,131 @@ +:numbered: +:toc: +:toc-placement: macro + += CIP2015-10-12 - CREATE + +*Authors:* Pontus Melke pontus.melke@neotechnology.com, Mats Rydberg mats@neotechnology.com + +toc::[] + +== Abstract +This proposal formalizes `CREATE` which is used in Cypher to create nodes and +relationships. + +== Motivation & Background +`CREATE` is how nodes and relationships are created in Cypher. The syntax has been around since the very beginning of Cypher but never properly +formalized. With 3.0 on the horizon we want to make sure `CREATE` fits with the +rest of the language, and make sure it is future proof. + +== Proposal + +`CREATE` will in a lot of aspects work as it does in the current implementation +but this proposal makes `CREATE` closer in syntax to how `MATCH` works. + +=== Examples + +*_Example:_* + +_Create a single node._ + +[source, cypher] +---- +CREATE () +---- + +_Create a node and set two labels and one property on it._ + +[source, cypher] +---- +CREATE (:Person:Administrator { email: 'mats@neotechnology.com' }) +---- + +_Create a relationship of type `KNOWS` between all `:Person` nodes._ + +[source, cypher] +---- +MATCH (a:Person), (b:Person) +CREATE (a)-[:KNOWS]->(b) +---- + +_Create two nodes and one relationship between them._ + +[source, cypher] +---- +CREATE (me:Source), (you:Destination), (you)<-[:LOVES]-(me) +---- + +_Create multiple nodes with properties from a parameter list of maps._ + +[source, cypher] +---- +UNWIND { mapList } AS map +CREATE (n:Node) +SET n = map +---- + +=== Syntax +[source, ebnf] +---- +create = "CREATE", {pattern}, [{",", pattern}] +pattern = node-pattern | rel-pattern; +node-pattern = "(", [identifier], [{label}], [property], ")" +rel-pattern = "(", identifier, ")", in-rel | out-rel, "(", identifier, ")" +out-rel = "-[", [identifier], type, [property], "]->" +in-rel = "<-[", [identifier], type, [property], "]-" +label = ":", identifier +type = label +property = "{", {identifier, ":", literal | param}, "}" +param = "{", identifier, "}" +literal = string | number +---- + +=== Interaction with existing features + +This proposal drops some functionality around how we handle creating +nodes and relationships: + + - `CREATE (a {param})` where `{param}` is either a map defining many properties + to be set on the node or a list of maps where one node is created for each item + of the list. We propose to remove both of these usages. + + - `CREATE (a)-[:T {param}]->(b)` where `{param}` is a map defining all properties + to be set on the relationship. + + - `CREATE (a:L {prop: 42})-[:R]->(b:B)` where both nodes and relationships are created + from the same pattern. With this proposal one would have to be more specific and write + `CREATE (a:L {prop:42}), (b:B), (a)-[:R]->(b)`. + +The rationale behind removing the use of parameter maps is to make `CREATE` behave +symmetrical to its non-mutating sibling `MATCH`. Furthermore, if we want to plan +for specific indexing write-operations, we need the information about the property +keys at the time of planning. + +The implicit creation of nodes when specifying a relationship pattern is +causing more complexity than whatever benefit it provides to the user. We +believe that forcing the user to be specific about what to create will benefit +both users and implementors of Cypher. + +=== Alternatives +The main alternative is to leave the functionality the way it is in Neo4j +versions prior to 3.0. We could also see alternatives where we don't remove all +of the above features but only a subset of them. + +== What others do + +- SQL has `CREATE TABLE` for creating tables and `INSERT` for creating new +records in a table. +- MongoDB has `create: ` for creating documents. +- In SPARQL, you use `INSERT DATA` to add triples. + +== Benefits to this proposal + +Since `CREATE` already exists in the language, this CIP doesn't introduce any new features, but instead +sends `CREATE` through this formal process, enabling us to clearly specify the behavior we want it to have. +A formal document such as this one could be of good value for a future language specification effort. The ideas we +present to constrain the `CREATE` syntax could also become valuable changes to the language in aligning `CREATE` +more symmetrically to `MATCH`. + +== Caveats to this proposal + +Not all syntax changes will have time to become deprecated in Cypher 2.3.0, but will have to be deprecated in a 2.3.x release. +This may or may not cause disturbance for users. From 78557a01c78f32998a6733ed0a7937dcac944dfa Mon Sep 17 00:00:00 2001 From: Mats Rydberg Date: Mon, 12 Oct 2015 18:12:20 +0200 Subject: [PATCH 2/7] Keep 'many-params' syntax for nodes and rels --- cip/CIP-2015-10-12-CREATE.adoc | 41 +++++++++++++++++----------------- 1 file changed, 20 insertions(+), 21 deletions(-) diff --git a/cip/CIP-2015-10-12-CREATE.adoc b/cip/CIP-2015-10-12-CREATE.adoc index 96e36fe44e..358ae2571c 100644 --- a/cip/CIP-2015-10-12-CREATE.adoc +++ b/cip/CIP-2015-10-12-CREATE.adoc @@ -13,14 +13,14 @@ This proposal formalizes `CREATE` which is used in Cypher to create nodes and relationships. == Motivation & Background -`CREATE` is how nodes and relationships are created in Cypher. The syntax has been around since the very beginning of Cypher but never properly -formalized. With 3.0 on the horizon we want to make sure `CREATE` fits with the -rest of the language, and make sure it is future proof. +`CREATE` is how nodes and relationships are created in Cypher. +The syntax has been around since the very beginning of Cypher but never properly formalized. +With 3.0 on the horizon we want to make sure `CREATE` fits with the rest of the language, and make sure it is future proof. == Proposal -`CREATE` will in a lot of aspects work as it does in the current implementation -but this proposal makes `CREATE` closer in syntax to how `MATCH` works. +`CREATE` will in a lot of aspects work as it does in the current implementation, +but this proposal cleans the `CREATE` syntax up a bit. === Examples @@ -63,6 +63,15 @@ CREATE (n:Node) SET n = map ---- +_Create two nodes with properties from two parameter maps. +Parameter keys and values will be the same as those of the map._ + +[source, cypher] +---- +CREATE (:Cat {catProps}) +CREATE (:Dog {dogProps}) +---- + === Syntax [source, ebnf] ---- @@ -74,7 +83,7 @@ out-rel = "-[", [identifier], type, [property], "]->" in-rel = "<-[", [identifier], type, [property], "]-" label = ":", identifier type = label -property = "{", {identifier, ":", literal | param}, "}" +property = "{", param | {identifier, ":", literal | param}, "}" param = "{", identifier, "}" literal = string | number ---- @@ -84,22 +93,13 @@ literal = string | number This proposal drops some functionality around how we handle creating nodes and relationships: - - `CREATE (a {param})` where `{param}` is either a map defining many properties - to be set on the node or a list of maps where one node is created for each item - of the list. We propose to remove both of these usages. - - - `CREATE (a)-[:T {param}]->(b)` where `{param}` is a map defining all properties - to be set on the relationship. + - `CREATE (a {param})` where `{param}` is a list of maps where one node is created for each item + of the list. We propose to remove this usage. - `CREATE (a:L {prop: 42})-[:R]->(b:B)` where both nodes and relationships are created from the same pattern. With this proposal one would have to be more specific and write `CREATE (a:L {prop:42}), (b:B), (a)-[:R]->(b)`. -The rationale behind removing the use of parameter maps is to make `CREATE` behave -symmetrical to its non-mutating sibling `MATCH`. Furthermore, if we want to plan -for specific indexing write-operations, we need the information about the property -keys at the time of planning. - The implicit creation of nodes when specifying a relationship pattern is causing more complexity than whatever benefit it provides to the user. We believe that forcing the user to be specific about what to create will benefit @@ -107,8 +107,7 @@ both users and implementors of Cypher. === Alternatives The main alternative is to leave the functionality the way it is in Neo4j -versions prior to 3.0. We could also see alternatives where we don't remove all -of the above features but only a subset of them. +versions prior to 3.0. == What others do @@ -122,8 +121,8 @@ records in a table. Since `CREATE` already exists in the language, this CIP doesn't introduce any new features, but instead sends `CREATE` through this formal process, enabling us to clearly specify the behavior we want it to have. A formal document such as this one could be of good value for a future language specification effort. The ideas we -present to constrain the `CREATE` syntax could also become valuable changes to the language in aligning `CREATE` -more symmetrically to `MATCH`. +present to constrain the `CREATE` syntax could also become valuable changes to the language in being slightly more +restrictive and thus slightly easier to understand. == Caveats to this proposal From 30d172e4960dea8dd873117fd77b4139cf8dc5c3 Mon Sep 17 00:00:00 2001 From: Mats Rydberg Date: Tue, 13 Oct 2015 12:02:19 +0200 Subject: [PATCH 3/7] Updated CIP to comply with new template Added semicolons to EBNF formula. --- cip/CIP-2015-10-12-CREATE.adoc | 130 --------------------------------- cip/CIP2015-10-12-CREATE.adoc | 124 +++++++++++++++++++++++++++++++ 2 files changed, 124 insertions(+), 130 deletions(-) delete mode 100644 cip/CIP-2015-10-12-CREATE.adoc create mode 100644 cip/CIP2015-10-12-CREATE.adoc diff --git a/cip/CIP-2015-10-12-CREATE.adoc b/cip/CIP-2015-10-12-CREATE.adoc deleted file mode 100644 index 358ae2571c..0000000000 --- a/cip/CIP-2015-10-12-CREATE.adoc +++ /dev/null @@ -1,130 +0,0 @@ -:numbered: -:toc: -:toc-placement: macro - -= CIP2015-10-12 - CREATE - -*Authors:* Pontus Melke pontus.melke@neotechnology.com, Mats Rydberg mats@neotechnology.com - -toc::[] - -== Abstract -This proposal formalizes `CREATE` which is used in Cypher to create nodes and -relationships. - -== Motivation & Background -`CREATE` is how nodes and relationships are created in Cypher. -The syntax has been around since the very beginning of Cypher but never properly formalized. -With 3.0 on the horizon we want to make sure `CREATE` fits with the rest of the language, and make sure it is future proof. - -== Proposal - -`CREATE` will in a lot of aspects work as it does in the current implementation, -but this proposal cleans the `CREATE` syntax up a bit. - -=== Examples - -*_Example:_* + -_Create a single node._ - -[source, cypher] ----- -CREATE () ----- - -_Create a node and set two labels and one property on it._ - -[source, cypher] ----- -CREATE (:Person:Administrator { email: 'mats@neotechnology.com' }) ----- - -_Create a relationship of type `KNOWS` between all `:Person` nodes._ - -[source, cypher] ----- -MATCH (a:Person), (b:Person) -CREATE (a)-[:KNOWS]->(b) ----- - -_Create two nodes and one relationship between them._ - -[source, cypher] ----- -CREATE (me:Source), (you:Destination), (you)<-[:LOVES]-(me) ----- - -_Create multiple nodes with properties from a parameter list of maps._ - -[source, cypher] ----- -UNWIND { mapList } AS map -CREATE (n:Node) -SET n = map ----- - -_Create two nodes with properties from two parameter maps. -Parameter keys and values will be the same as those of the map._ - -[source, cypher] ----- -CREATE (:Cat {catProps}) -CREATE (:Dog {dogProps}) ----- - -=== Syntax -[source, ebnf] ----- -create = "CREATE", {pattern}, [{",", pattern}] -pattern = node-pattern | rel-pattern; -node-pattern = "(", [identifier], [{label}], [property], ")" -rel-pattern = "(", identifier, ")", in-rel | out-rel, "(", identifier, ")" -out-rel = "-[", [identifier], type, [property], "]->" -in-rel = "<-[", [identifier], type, [property], "]-" -label = ":", identifier -type = label -property = "{", param | {identifier, ":", literal | param}, "}" -param = "{", identifier, "}" -literal = string | number ----- - -=== Interaction with existing features - -This proposal drops some functionality around how we handle creating -nodes and relationships: - - - `CREATE (a {param})` where `{param}` is a list of maps where one node is created for each item - of the list. We propose to remove this usage. - - - `CREATE (a:L {prop: 42})-[:R]->(b:B)` where both nodes and relationships are created - from the same pattern. With this proposal one would have to be more specific and write - `CREATE (a:L {prop:42}), (b:B), (a)-[:R]->(b)`. - -The implicit creation of nodes when specifying a relationship pattern is -causing more complexity than whatever benefit it provides to the user. We -believe that forcing the user to be specific about what to create will benefit -both users and implementors of Cypher. - -=== Alternatives -The main alternative is to leave the functionality the way it is in Neo4j -versions prior to 3.0. - -== What others do - -- SQL has `CREATE TABLE` for creating tables and `INSERT` for creating new -records in a table. -- MongoDB has `create: ` for creating documents. -- In SPARQL, you use `INSERT DATA` to add triples. - -== Benefits to this proposal - -Since `CREATE` already exists in the language, this CIP doesn't introduce any new features, but instead -sends `CREATE` through this formal process, enabling us to clearly specify the behavior we want it to have. -A formal document such as this one could be of good value for a future language specification effort. The ideas we -present to constrain the `CREATE` syntax could also become valuable changes to the language in being slightly more -restrictive and thus slightly easier to understand. - -== Caveats to this proposal - -Not all syntax changes will have time to become deprecated in Cypher 2.3.0, but will have to be deprecated in a 2.3.x release. -This may or may not cause disturbance for users. diff --git a/cip/CIP2015-10-12-CREATE.adoc b/cip/CIP2015-10-12-CREATE.adoc new file mode 100644 index 0000000000..116e464d3c --- /dev/null +++ b/cip/CIP2015-10-12-CREATE.adoc @@ -0,0 +1,124 @@ += CIP2015-10-12 - CREATE +:numbered: +:toc: +:toc-placement: macro +:source-highlighter: codemirror + +*Authors:* Pontus Melke pontus.melke@neotechnology.com, Mats Rydberg mats@neotechnology.com + +[abstract] +.Abstract +-- +This proposal formalizes `CREATE` which is used in Cypher to create nodes and relationships. +-- + +toc::[] + +== Motivation & Background +`CREATE` is how nodes and relationships are created in Cypher. +The syntax has been around since the very beginning of Cypher but never properly formalized. +With 3.0 on the horizon we want to make sure `CREATE` fits with the rest of the language, and make sure it is future proof. + +== Proposal + +`CREATE` will in a lot of aspects work as it does in the current implementation, but this proposal cleans the `CREATE` syntax up a bit. + +=== Examples + +[source, cypher] +.Create a single node. +---- +CREATE () +---- + +[source, cypher] +.Create a node and set two labels and one property on it. +---- +CREATE (:Person:Administrator { email: 'mats@neotechnology.com' }) +---- + +[source, cypher] +.Create a relationship of type `KNOWS` between all `:Person` nodes. +---- +MATCH (a:Person), (b:Person) +CREATE (a)-[:KNOWS]->(b) +---- + +[source, cypher] +.Create two nodes and one relationship between them. +---- +CREATE (me:Source), (you:Destination), (you)<-[:LOVES]-(me) +---- + +[source, cypher] +.Create multiple nodes with properties from a parameter list of maps. +---- +UNWIND { mapList } AS map +CREATE (n:Node) +SET n = map +---- + +[source, cypher] +// It seems the . operator doesn't allow multiple lines, and we want two sentences here. +.Create two nodes with properties from two parameter maps. Parameter keys and values will be the same as those of the map. +---- +CREATE (:Cat {catProps}) +CREATE (:Dog {dogProps}) +---- + +=== Syntax +[source, ebnf] +---- +create = "CREATE", {pattern}, [{",", pattern}] ; +pattern = node-pattern | rel-pattern ; +node-pattern = "(", [identifier], [{label}], [property], ")" ; +rel-pattern = "(", identifier, ")", in-rel | out-rel, "(", identifier, ")" ; +out-rel = "-[", [identifier], type, [property], "]->" ; +in-rel = "<-[", [identifier], type, [property], "]-" ; +label = ":", identifier ; +type = label ; +property = "{", param | {identifier, ":", literal | param}, "}" ; +param = "{", identifier, "}" ; +literal = string | number ; +---- + +=== Semantics + +`CREATE` is used to create new nodes and relationships in the graph. +Each `CREATE` will create exactly one node or one relationship between two pre-existing nodes per row. +`CREATE` has no return value, and ending a query with a `CREATE` clause will yield an empty result. + +=== Interaction with existing features + +`CREATE` on a node pattern will cause the query to fail in the commit phase if the to-be-created node would violate a uniqueness constraint in the database. + +This proposal drops some functionality around how we handle creating nodes and relationships: + +- `CREATE (a {param})` where `{param}` is a list of maps where one node is created for each item of the list. +We propose to remove this usage. + +- `CREATE (a:L {prop: 42})-[:R]->(b:B)` where both nodes and relationships are created from the same pattern. +With this proposal one would have to be more specific and write `CREATE (a:L {prop:42}), (b:B), (a)-[:R]->(b)`. + +We believe that the implicit creation of nodes when specifying a relationship pattern is causing more complexity than whatever benefit it provides to the user, and thus forcing the user to be specific about what to create will benefit both users and implementors of Cypher. + +=== Alternatives +The main alternative is to leave the functionality the way it is in Neo4j versions prior to 3.0. + +== What others do + +- SQL has `CREATE TABLE` for creating tables and `INSERT` for creating new records in a table. +- MongoDB has `create: ` for creating documents. +- In SPARQL, you use `INSERT DATA` to add triples. + +== Benefits to this proposal + +Since `CREATE` already exists in the language, this CIP doesn't introduce any new features, the goal is rather to send `CREATE` through a formalization process. +Hopefully this will enable us to clearly specify the behavior we want `CREATE` to have. +A formal document such as this one could be of good value for a future language specification effort. +The ideas we present to constrain the `CREATE` syntax could also become valuable changes to the language in being slightly more restrictive and thus slightly easier to understand. + +== Caveats to this proposal + +Not all syntax changes will have time to become deprecated in Cypher 2.3.0, but will have to be deprecated in a 2.3.x release. +This may or may not cause disturbance for users. From f1483f9fa709a78997b641eb3eb104a6d5f41655 Mon Sep 17 00:00:00 2001 From: Mats Rydberg Date: Tue, 13 Oct 2015 13:29:30 +0200 Subject: [PATCH 4/7] Update cip from comments * Remove caveats section. * Add example of path creation and mention suggestion of removal of old way. --- cip/CIP2015-10-12-CREATE.adoc | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/cip/CIP2015-10-12-CREATE.adoc b/cip/CIP2015-10-12-CREATE.adoc index 116e464d3c..b94e92f2b9 100644 --- a/cip/CIP2015-10-12-CREATE.adoc +++ b/cip/CIP2015-10-12-CREATE.adoc @@ -45,9 +45,9 @@ CREATE (a)-[:KNOWS]->(b) ---- [source, cypher] -.Create two nodes and one relationship between them. +.Create two nodes, one relationship between them, and sets one property on the relationship. ---- -CREATE (me:Source), (you:Destination), (you)<-[:LOVES]-(me) +CREATE (me:Source), (you:Destination), (you)<-[:LOVES { dearly: true }]-(me) ---- [source, cypher] @@ -66,6 +66,17 @@ CREATE (:Cat {catProps}) CREATE (:Dog {dogProps}) ---- +[source, cypher] +.Create three nodes, connect them with two relationships and return the whole pattern as a path. +---- +CREATE (andres { name: 'Andres' }) +CREATE (neo) +CREATE (michael { name: 'Michael' }) +CREATE (andres)-[r1:WORKS_AT]->(neo) +CREATE (michael)-[r2:WORKS_AT]->(neo) +RETURN (andres)-[r1]->(neo)<-[r2]-(michael) AS p +---- + === Syntax [source, ebnf] ---- @@ -94,16 +105,19 @@ Each `CREATE` will create exactly one node or one relationship between two pre-e This proposal drops some functionality around how we handle creating nodes and relationships: -- `CREATE (a {param})` where `{param}` is a list of maps where one node is created for each item of the list. -We propose to remove this usage. +- `CREATE (a {param})` where `{param}` is a list of maps where one node is created for each item in the list. +See the example with `UNWIND` above for a way to achieve the same behavior. - `CREATE (a:L {prop: 42})-[:R]->(b:B)` where both nodes and relationships are created from the same pattern. With this proposal one would have to be more specific and write `CREATE (a:L {prop:42}), (b:B), (a)-[:R]->(b)`. +- `CREATE p = (andres { name: 'Andres' })-[:WORKS_AT]->(neo)<-[:WORKS_AT]-(michael { name:'Michael' }) RETURN p`, where a full path is created and returned. +See the final example above for how to achieve the same behaviour. + We believe that the implicit creation of nodes when specifying a relationship pattern is causing more complexity than whatever benefit it provides to the user, and thus forcing the user to be specific about what to create will benefit both users and implementors of Cypher. === Alternatives -The main alternative is to leave the functionality the way it is in Neo4j versions prior to 3.0. +The main alternative is to leave the functionality the way it is in Cypher versions prior to 3.0. == What others do @@ -117,8 +131,3 @@ Since `CREATE` already exists in the language, this CIP doesn't introduce any ne Hopefully this will enable us to clearly specify the behavior we want `CREATE` to have. A formal document such as this one could be of good value for a future language specification effort. The ideas we present to constrain the `CREATE` syntax could also become valuable changes to the language in being slightly more restrictive and thus slightly easier to understand. - -== Caveats to this proposal - -Not all syntax changes will have time to become deprecated in Cypher 2.3.0, but will have to be deprecated in a 2.3.x release. -This may or may not cause disturbance for users. From 9b50ce06cdc928d86d264f40020dac8114a0d569 Mon Sep 17 00:00:00 2001 From: Mats Rydberg Date: Tue, 13 Oct 2015 14:16:10 +0200 Subject: [PATCH 5/7] Replace referral to implementation with explanation --- cip/CIP2015-10-12-CREATE.adoc | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/cip/CIP2015-10-12-CREATE.adoc b/cip/CIP2015-10-12-CREATE.adoc index b94e92f2b9..3a64111fc0 100644 --- a/cip/CIP2015-10-12-CREATE.adoc +++ b/cip/CIP2015-10-12-CREATE.adoc @@ -21,7 +21,12 @@ With 3.0 on the horizon we want to make sure `CREATE` fits with the rest of the == Proposal -`CREATE` will in a lot of aspects work as it does in the current implementation, but this proposal cleans the `CREATE` syntax up a bit. +`CREATE` is used to create new nodes and relationships into the graph, as well as set initial labels, type, and properties on the new entities. +The idea is to let each `CREATE` represent exactly one creation of either a node or a relationship, but allow a few variations on how to structure the query for convenience. +`CREATE` will be allowed to both start and end a query, requiring an additional `WITH` clause to allow further `MATCH` reads after it, and producing an empty result if it ends the query. +`MATCH` clauses that come after a `CREATE` clause must be able to see and possibly match _all_ entities created by the `CREATE`; not only those created for the same row. + +A `CREATE` will always succeed unless it specifically violates some constraint already present in the database. === Examples From 9783c503376e78e4f7a6f713fc7288b676072f8a Mon Sep 17 00:00:00 2001 From: Mats Rydberg Date: Tue, 13 Oct 2015 16:14:42 +0200 Subject: [PATCH 6/7] Explicitly acknowledge CIP as retroactive --- cip/CIP2015-10-12-CREATE.adoc | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/cip/CIP2015-10-12-CREATE.adoc b/cip/CIP2015-10-12-CREATE.adoc index 3a64111fc0..0c10a6da7a 100644 --- a/cip/CIP2015-10-12-CREATE.adoc +++ b/cip/CIP2015-10-12-CREATE.adoc @@ -16,8 +16,7 @@ toc::[] == Motivation & Background `CREATE` is how nodes and relationships are created in Cypher. -The syntax has been around since the very beginning of Cypher but never properly formalized. -With 3.0 on the horizon we want to make sure `CREATE` fits with the rest of the language, and make sure it is future proof. +The syntax has been around since Cypher 1.7 but never properly formalized. == Proposal @@ -122,7 +121,8 @@ See the final example above for how to achieve the same behaviour. We believe that the implicit creation of nodes when specifying a relationship pattern is causing more complexity than whatever benefit it provides to the user, and thus forcing the user to be specific about what to create will benefit both users and implementors of Cypher. === Alternatives -The main alternative is to leave the functionality the way it is in Cypher versions prior to 3.0. +This is a retroactive CIP. +`CREATE` already exists in the language. == What others do @@ -132,7 +132,5 @@ The main alternative is to leave the functionality the way it is in Cypher versi == Benefits to this proposal -Since `CREATE` already exists in the language, this CIP doesn't introduce any new features, the goal is rather to send `CREATE` through a formalization process. -Hopefully this will enable us to clearly specify the behavior we want `CREATE` to have. -A formal document such as this one could be of good value for a future language specification effort. -The ideas we present to constrain the `CREATE` syntax could also become valuable changes to the language in being slightly more restrictive and thus slightly easier to understand. +This is a retroactive CIP, and proposes no new features. +The purpose of this proposal is this very CIP, formalizing what we want `CREATE` to be. From 31f2dc8fc4b4ae2147d260d22c80fb91c42b71b6 Mon Sep 17 00:00:00 2001 From: Mats Rydberg Date: Tue, 27 Oct 2015 09:53:36 +0100 Subject: [PATCH 7/7] Improve language and clarify purpose --- cip/CIP2015-10-12-CREATE.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/cip/CIP2015-10-12-CREATE.adoc b/cip/CIP2015-10-12-CREATE.adoc index 0c10a6da7a..802239c743 100644 --- a/cip/CIP2015-10-12-CREATE.adoc +++ b/cip/CIP2015-10-12-CREATE.adoc @@ -10,6 +10,7 @@ .Abstract -- This proposal formalizes `CREATE` which is used in Cypher to create nodes and relationships. +Please note that `CREATE UNIQUE` and `CREATE CONSTRAINT` are _not_ considered in this CIP. -- toc::[] @@ -20,7 +21,7 @@ The syntax has been around since Cypher 1.7 but never properly formalized. == Proposal -`CREATE` is used to create new nodes and relationships into the graph, as well as set initial labels, type, and properties on the new entities. +`CREATE` is used to add new nodes and relationships to the graph, as well as set initial labels, type, and properties on the new entities. The idea is to let each `CREATE` represent exactly one creation of either a node or a relationship, but allow a few variations on how to structure the query for convenience. `CREATE` will be allowed to both start and end a query, requiring an additional `WITH` clause to allow further `MATCH` reads after it, and producing an empty result if it ends the query. `MATCH` clauses that come after a `CREATE` clause must be able to see and possibly match _all_ entities created by the `CREATE`; not only those created for the same row. @@ -63,7 +64,6 @@ SET n = map ---- [source, cypher] -// It seems the . operator doesn't allow multiple lines, and we want two sentences here. .Create two nodes with properties from two parameter maps. Parameter keys and values will be the same as those of the map. ---- CREATE (:Cat {catProps}) @@ -118,7 +118,7 @@ With this proposal one would have to be more specific and write `CREATE (a:L {pr - `CREATE p = (andres { name: 'Andres' })-[:WORKS_AT]->(neo)<-[:WORKS_AT]-(michael { name:'Michael' }) RETURN p`, where a full path is created and returned. See the final example above for how to achieve the same behaviour. -We believe that the implicit creation of nodes when specifying a relationship pattern is causing more complexity than whatever benefit it provides to the user, and thus forcing the user to be specific about what to create will benefit both users and implementors of Cypher. +We believe that the implicit creation of nodes when specifying a relationship pattern is causing more complexity than any benefit provided to the user, and thus forcing the user to be specific about what to create will benefit both users and implementors of Cypher. === Alternatives This is a retroactive CIP.