diff --git a/modules/ROOT/pages/constraints/index.adoc b/modules/ROOT/pages/constraints/index.adoc index 4bcf3b3e0..cf56b8765 100644 --- a/modules/ROOT/pages/constraints/index.adoc +++ b/modules/ROOT/pages/constraints/index.adoc @@ -3,47 +3,76 @@ [[constraints]] = Constraints -This page contains an overview of the available constraints in Cypher. +This page contains an overview of the available constraints in Cypher, and information about how constraints can impact indexes. -[[types-of-constraint]] -== Types of constraint +Adding constraints is an atomic operation that can take a while -- all existing data has to be scanned before a Neo4j DBMS can use a constraint. -The following constraint types are available: - -*Unique node property constraints*:: +[[unique-node-property]] +== Unique node property constraints Unique node property constraints, or node property uniqueness constraints, ensure that property values are unique for all nodes with a specific label. For property uniqueness constraints on multiple properties, the combination of the property values is unique. Node property uniqueness constraints do not require all nodes to have a unique value for the properties listed (nodes without all properties on which the constraint exists are not subject to this rule). -*Unique relationship property constraints* label:new[Introduced in 5.7]:: +For more information, see xref:constraints/examples.adoc#constraints-examples-node-uniqueness[examples of node property uniqueness constraints]. + +[[unique-relationship-property]] +== Unique relationship property constraints +label:new[Introduced in 5.7] + Unique relationship property constraints, or relationship property uniqueness constraints, ensure that property values are unique for all relationships with a specific type. For property uniqueness constraints on multiple properties, the combination of the property values is unique. Relationship property uniqueness constraints do not require all relationships to have a unique value for the properties listed (relationships without all properties on which the constraint exists are not subject to this rule). -*Node property existence constraints* label:enterprise-edition[]:: +For more information, see xref:constraints/examples.adoc#constraints-examples-relationship-uniqueness[examples of relationship property uniqueness constraints]. + +[[node-property-existence]] +[role=enterprise-edition] +== Node property existence constraints + Node property existence constraints ensure that a property exists for all nodes with a specific label. Queries that try to create new nodes of the specified label, but without this property, will fail. The same is true for queries that try to remove the mandatory property. -*Relationship property existence constraints* label:enterprise-edition[]:: +For more information, see xref:constraints/examples.adoc#constraints-examples-node-property-existence[examples of node property existence constraints]. + +[[relationship-property-existence]] +[role=enterprise-edition] +== Relationship property existence constraints + Relationship property existence constraints ensure that a property exists for all relationships with a specific type. All queries that try to create relationships of the specified type, but without this property, will fail. The same is true for queries that try to remove the mandatory property. -*Node property type constraints* label:new[Introduced in 5.9] label:enterprise-edition[]:: +For more information, see xref:constraints/examples.adoc#constraints-examples-relationship-property-existence[examples of relationship property existence constraints]. + +[[node-property-type]] +[role=enterprise-edition] +== Node property type constraints +label:new[Introduced in 5.9] + Node property type constraints ensure that a property have the required property type for all nodes with a specific label. Queries that try to add or modify this property to nodes of the specified label, but with a different property type, will fail. Node property type constraints do not require all nodes to have the property (nodes without the property on which the constraint exists are not subject to this rule). -*Relationship property type constraints* label:new[Introduced in 5.9] label:enterprise-edition[]:: +For more information, see xref:constraints/examples.adoc#constraints-examples-node-property-type[examples of node property type constraints]. + +[[relationship-property-type]] +[role=enterprise-edition] +== Relationship property type constraints +label:new[Introduced in 5.9] + Relationship property type constraints ensure that a property have the required property type for all relationships with a specific type. Queries that try to add or modify this property to relationships of the specified type, but with a different property type, will fail. Relationship property type constraints do not require all relationships to have the property (relationships without the property on which the constraint exists are not subject to this rule). -*Node key constraints* label:enterprise-edition[]:: +For more information, see xref:constraints/examples.adoc#constraints-examples-relationship-property-type[examples of relationship property type constraints]. + +[[node-key]] +[role=enterprise-edition] +== Node key constraints + Node key constraints ensure that, for a given label and set of properties: -+ -[lowerroman] + . All the properties exist on all the nodes with that label. . The combination of the property values is unique. @@ -54,9 +83,15 @@ Queries attempting to do any of the following will fail: * Remove one of the mandatory properties. * Update the properties so that the combination of property values is no longer unique. -*Relationship key constraints* label:new[Introduced in 5.7] label:enterprise-edition[]:: +For more information, see xref:constraints/examples.adoc#constraints-examples-node-key[examples of node key constraints]. + +[[relationship-key]] +[role=enterprise-edition] +== Relationship key constraints +label:new[Introduced in 5.7] + Relationship key constraints ensure that, for a given type and set of properties: -+ + [lowerroman] . All the properties exist on all the relationships with that type. . The combination of the property values is unique. @@ -68,17 +103,17 @@ Queries attempting to do any of the following will fail: * Remove one of the mandatory properties. * Update the properties so that the combination of property values is no longer unique. +For more information, see xref:constraints/examples.adoc#constraints-examples-relationship-key[examples of relationship key constraints]. + +[[multiple-constrains]] +== Multiple constraints on the same property combinations -[NOTE] -==== -Node key constraints, relationship key constraints, node property existence constraints, relationship property existence, node property type constraints, and relationship property type constraints are not available in Neo4j Community Edition. -Databases containing one of these constraint types cannot be opened using Neo4j Community Edition. -==== Some constraint types are allowed on the same label/relationship type and property combination. For example, it is possible to have a uniqueness and an existence constraint on the same label/relationship type and property combination, though this would be the equivalent of having a node or relationship key constraint. A more useful example would be to combine a property type and an existence constraint to ensure that the property exists and has the given type. +[[index-implications]] == Implications on indexes Creating a constraint has the following implications on indexes: @@ -89,13 +124,3 @@ Creating a constraint has the following implications on indexes: Refer to xref::indexes-for-search-performance.adoc[] for more details on indexes. * If a node key, relationship key, or property uniqueness constraint is dropped and the backing index is still required, the index need to be created explicitly. -Additionally, the following is true for constraints: - -* A given label or relationship type can have multiple constraints, and uniqueness and property existence constraints can be combined on the same property. -* Adding constraints is an atomic operation that can take a while -- all existing data has to be scanned before Neo4j DBMS can turn the constraint 'on'. -* Best practice is to give the constraint a name when it is created. -If the constraint is not explicitly named, it will get an auto-generated name. -* The constraint name must be unique among both indexes and constraints. -* Constraint creation is by default not idempotent, and an error will be thrown if you attempt to create the same constraint twice. -Using the keyword `IF NOT EXISTS` makes the command idempotent, and no error will be thrown if you attempt to create the same constraint twice. -