Examples

When creating a node property existence constraint, a name can be provided. The constraint ensures that all nodes with a certain label have a certain property.

If it is not known whether a constraint exists or not, add IF NOT EXISTS to ensure it does. The node property existence constraint ensures that all nodes with a certain label have a certain property.

Note no constraint will be created if any other constraint with that name or another node property existence constraint on the same schema already exists. Assuming a constraint with the name constraint_name already existed:

Create a node property existence constraint on the property title on nodes with the Book label, when that constraint already exists.

In this case the constraint can’t be created because it already exists.

Create a Book node with an isbn property.

Trying to create a Book node without an isbn property, given a property existence constraint on :Book(isbn).

In this case the node isn’t created in the graph.

Trying to remove the isbn property from an existing node book, given a property existence constraint on :Book(isbn).

In this case the property is not removed.

Create a constraint on the property isbn on nodes with the Book label when there already exists a node without an isbn.

In this case the constraint can’t be created because it is violated by existing data. We may choose to remove the offending nodes and then re-apply the constraint.

When creating a relationship property existence constraint, a name can be provided. The constraint ensures all relationships with a certain type have a certain property.

If it is not known whether a constraint exists or not, add IF NOT EXISTS to ensure it does. The relationship property existence constraint ensures all relationships with a certain type have a certain property.

Note no constraint will be created if any other constraint with that name or another relationship property existence constraint on the same schema already exists. Assuming a constraint with the name constraint_name already existed:

Create a named relationship property existence constraint on the property week on relationships with the LIKED type, when a constraint with that name already exists.

In this case the constraint can’t be created because there already exists a constraint with that name.

Create a LIKED relationship with a day property.

Trying to create a LIKED relationship without a day property, given a property existence constraint :LIKED(day).

In this case the relationship isn’t created in the graph.

Trying to remove the day property from an existing relationship like of type LIKED, given a property existence constraint :LIKED(day).

In this case the property is not removed.

Create a constraint on the property day on relationships with the LIKED type when there already exists a relationship without a property named day.

In this case the constraint can’t be created because it is violated by existing data. We may choose to remove the offending relationships and then re-apply the constraint.

When creating a node key constraint, a name can be provided. The constraint ensures that all nodes with a particular label have a set of defined properties whose combined value is unique and all properties in the set are present.

If it is not known whether a constraint exists or not, add IF NOT EXISTS to ensure it does. The node key constraint ensures that all nodes with a particular label have a set of defined properties whose combined value is unique and all properties in the set are present.

Note no constraint will be created if any other constraint with that name or another node key constraint on the same schema already exists. Assuming a node key constraint on (:Person {firstname, surname}) already existed:

To create a node key constraint with a specific index provider for the backing index, the OPTIONS clause is used. Valid values for the index provider are native-btree-1.0 (deprecated), lucene+native-3.0 (deprecated), and range-1.0 (future index), default is native-btree-1.0. The index type of the backing index is set depending on the provider, the range-1.0 generates a future range index while the other providers generates a b-tree index. In 4.4, b-tree index-backed constraints are still the correct alternative to use.

B-tree providers can be combined with specifying index configuration.

To create a node key constraint with a specific index configuration for the backing index, the OPTIONS clause is used. The index type of the backing index is set depending on the provider and future range indexes have no configuration settings. The valid b-tree configuration settings are

Non-specified settings have their respective default values.

Can be combined with specifying a b-tree index provider.

Create a node key constraint on the properties firstname and age on nodes with the Person label, when a unique property constraint already exists on the same label and property combination.

In this case the constraint can’t be created because there already exist a conflicting constraint on that label and property combination.

Create a named node key constraint on the property title on nodes with the Book label, when an index already exists with that name.

In this case the constraint can’t be created because there already exists an index with that name.

Create a Person node with both a firstname and surname property.

Trying to create a Person node without a surname property, given a node key constraint on :Person(firstname, surname), will fail.

In this case the node isn’t created in the graph.

Trying to remove the surname property from an existing node Person, given a NODE KEY constraint on :Person(firstname, surname).

In this case the property is not removed.

Trying to create a node key constraint on the property surname on nodes with the Person label will fail when a node without a surname already exists in the database.

In this case the node key constraint can’t be created because it is violated by existing data. We may choose to remove the offending nodes and then re-apply the constraint.