Syntax

Syntax for creating constraints

Best practice when creating a constraint is to give the constraint a name. This name must be unique among both indexes and constraints. If a name is not explicitly given, a unique name will be auto-generated.

The create constraint command is optionally idempotent, with the default behavior to throw an error if you attempt to create the same constraint twice. With the IF NOT EXISTS flag, no error is thrown and nothing happens should a constraint with the same name or same schema and constraint type already exist. It may still throw an error if conflicting data, indexes, or constraints exist. Examples of this are nodes with missing properties, indexes with the same name, or constraints with same schema but a different constraint type.

For constraints that are backed by an index, the index provider and configuration for the backing index can be specified using the OPTIONS clause.

Creating a constraint requires the CREATE CONSTRAINT privilege.

Create a unique node property constraint

This command creates a uniqueness constraint on nodes with the specified label and property.

CREATE CONSTRAINT [constraint_name] [IF NOT EXISTS]
ON (n:LabelName)
ASSERT n.propertyName IS UNIQUE
[OPTIONS "{" option: value[, ...] "}"]

Create a node property existence constraint

This command creates a property existence constraint on nodes with the specified label and property.

CREATE CONSTRAINT [constraint_name] [IF NOT EXISTS]
ON (n:LabelName)
ASSERT n.propertyName IS NOT NULL

Create a relationship property existence constraint

This command creates a property existence constraint on relationships with the specified relationship type and property.

CREATE CONSTRAINT [constraint_name] [IF NOT EXISTS]
ON ()-"["R:RELATIONSHIP_TYPE"]"-()
ASSERT R.propertyName IS NOT NULL

Create a node key constraint

This command creates a node key constraint on nodes with the specified label and properties.

CREATE CONSTRAINT [constraint_name] [IF NOT EXISTS]
ON (n:LabelName)
ASSERT (n.propertyName_1,
n.propertyName_2,
…
n.propertyName_n)
IS NODE KEY
[OPTIONS "{" option: value[, ...] "}"]

Syntax for dropping constraints

Drop a constraint

The preferred way of dropping a constraint is by the name of the constraint.

This drop command is optionally idempotent, with the default behavior to throw an error if you attempt to drop the same constraint twice. With the IF EXISTS flag, no error is thrown and nothing happens should the constraint not exist.

Dropping a constraint requires the DROP CONSTRAINT privilege.

DROP CONSTRAINT constraint_name [IF EXISTS]

Drop a unique constraint without specifying a name

An old way of dropping a uniqueness constraint was to drop the constraint by specifying the schema of the constraint.

DROP CONSTRAINT
ON (n:LabelName)
ASSERT n.propertyName IS UNIQUE

Drop a node property existence constraint without specifying a name

An old way of dropping a node property existence constraint was to drop the constraint by specifying the schema of the constraint.

DROP CONSTRAINT
ON (n:LabelName)
ASSERT EXISTS (n.propertyName)

Drop a relationship property existence constraint without specifying a name

An old way of dropping a relationship property existence constraint was to drop the constraint by specifying the schema of the constraint.

DROP CONSTRAINT
ON ()-"["R:RELATIONSHIP_TYPE"]"-()
ASSERT EXISTS (R.propertyName)

Drop a node key constraint without specifying a name

An old way of dropping a node key constraint was to drop the constraint by specifying the schema of the constraint.

DROP CONSTRAINT
ON (n:LabelName)
ASSERT (n.propertyName_1,
n.propertyName_2,
…
n.propertyName_n)
IS NODE KEY

Syntax for listing constraints

List constraints in the database, either all or filtered on constraint type. This requires the SHOW CONSTRAINT privilege.

The simple version of the command allows for a WHERE clause and will give back the default set of output columns:

SHOW [ALL|UNIQUE|NODE [PROPERTY] EXIST[ENCE]|REL[ATIONSHIP] [PROPERTY] EXIST[ENCE]|[PROPERTY] EXIST[ENCE]|NODE KEY] CONSTRAINT[S]
    [WHERE expression]

To get the full set of output columns, a yield clause is needed:

SHOW [ALL|UNIQUE|NODE [PROPERTY] EXIST[ENCE]|REL[ATIONSHIP] [PROPERTY] EXIST[ENCE]|[PROPERTY] EXIST[ENCE]|NODE KEY] CONSTRAINT[S]
    YIELD { * | field[, ...] } [ORDER BY field[, ...]] [SKIP n] [LIMIT n]
    [WHERE expression]
    [RETURN field[, ...] [ORDER BY field[, ...]] [SKIP n] [LIMIT n]]

The returned columns from the show command is:

Table 1. List constraints output
Column	Description	Default output	Full output
`id`	The id of the constraint.
`name`	Name of the constraint (explicitly set by the user or automatically assigned).
`type`	The ConstraintType of this constraint (`UNIQUENESS`, `NODE_PROPERTY_EXISTENCE`, `NODE_KEY`, or `RELATIONSHIP_PROPERTY_EXISTENCE`).
`entityType`	Type of entities this constraint represents (nodes or relationship).
`labelsOrTypes`	The labels or relationship types of this constraint.
`properties`	The properties of this constraint.
`ownedIndexId`	The id of the index associated to the constraint, or `null` if no index is associated with the constraint.
`options`	The options passed to `CREATE` command, for the index associated to the constraint, or `null` if no index is associated with the constraint.
`createStatement`	Statement used to create the constraint.

The deprecated built-in procedures for listing constraints, such as db.constraints, work as before and are not affected by the SHOW CONSTRAINTS privilege.