Overview
Constraints enforce rules for data that can go into a graph. Any data modification that violates a constraint will result in an error.
The following constraints are supported:
Creating Constraints
A constraint is created with the CREATE CONSTRAINT
statement. The constraint creation is executed as a job, you may run show().job()
afterward to verify the success of the creation.
Creating a constraint can take some time, as the system needs to scan all existing data for compliance with the constraint. The creation process will fail if any existing data does not meet the constraint. Additionally, to ensure data consistency, other data modifications are put on hold during the constraint creation process.
EDGE KEY
The EDGE KEY
constraint specifies an edge property effectively as the unique identifier for edges. Thus, the specified property must be present in all edge schemas with a consistent value type and must contain unique, non-null
values across the graph.
Details
- A graph can have only one
EDGE KEY
constraint. - The
EDGE KEY
constraint cannot be applied to an edge property of thelist
type. - The edge property involved in the
EDGE KEY
constraint is automatically cached to accelerate query performance. - The
*
must be used to apply theEDGE KEY
constraint across all edge schemas. - The
EDGE KEY
constraint creation enforces uniqueness among property values within each shard, allowing duplicates across different shards. However, any data modifications made after theEDGE KEY
constraint is created must adhere to global uniqueness.
To create an EDGE KEY
constraint named eUID
on the edge property createdOn
:
CREATE CONSTRAINT eUID
FOR ()-[e]-() REQUIRE e.createdOn IS EDGE KEY
OPTIONS {
type: {createdOn: "datetime"}
}
This constraint can only be successfully created if the following conditions are met:
- All edge schemas have a property named
createdOn
, and it must be of the typedatetime
. - The
createdOn
property must not contain duplicate values in each shard ornull
values.
Default Property Value Type
When the property value type is not specified, it defaults to string
:
CREATE CONSTRAINT eUID
FOR ()-[e]-() REQUIRE e.createdOn IS EDGE KEY
In this case, all edge schemas must have a createdOn
property of the type string
.
Composite EDGE KEY Constraint
A composite EDGE KEY
constraint involves multiple edge properties. The requirements remain the same as those for a single-property EDGE KEY
, except that uniqueness is enforced based on the combined values of the specified properties.
To create a composite EDGE KEY
constraint named eUIDs
on the edge properties createdOn
and weight
:
CREATE CONSTRAINT eUIDs
FOR ()-[e]-() REQUIRE (e.createdOn, e.weight) IS EDGE KEY
OPTIONS {
type: {createdOn: "datetime", weight: "float"}
}
NOT NULL
The NOT NULL
constraint enforces a property cannot have null
values, ensuring that a value is always provided.
Details
- A
NOT NULL
constraint must be created for a single specified schema. - Only one property can be designated per
NOT NULL
constraint.
To create a NOT NULL
constraint named nn_1
on the property name
of the user
nodes:
CREATE CONSTRAINT nn_1
FOR (u:user) REQUIRE u.name IS NOT NULL
To create a NOT NULL
constraint named nn_2
on the property weight
of the link
edges:
CREATE CONSTRAINT nn_2
FOR ()-[e:link]-() REQUIRE e.weight IS NOT NULL
These constraints can only be successfully created when there is no null
values exist in the specified property.
Using the IF NOT EXISTS Flag
Constraint names in a graph must be unique. If you attempt to create a constraint with a name that already exists, the creation will fail, and an error message will indicate the duplication.
With the IF NOT EXISTS
flag, the job will complete with a FINISHED
status when a duplicate name is detected. No error message will be returned, and no new constraint is created.
To create a NOT NULL
constraint named nn_1
. If the constraint name already exists, skip the creation without returning an error message:
CREATE CONSTRAINT nn_1
FOR (u:user) REQUIRE u.age IS NOT NULL
Showing Constraints
To retrieve information about constraints created in the current graph:
// Shows all constraints
show().constraint()
// Shows all constraints created on node properties
show().node_constraint()
// Shows all constraints created on edge properties
show().edge_constraint()
The information about constraints is organized into the _nodeConstraint
or _edgeConstraint
table. Each table includes fields that provide essential details about each constraint:
Field |
Description |
---|---|
name |
Constraint name. |
type |
Constraint type. |
schema |
The node or edge schemas where the constraint applies. |
properties |
The node or edge properties where the constraint applies. |
status |
Constraint status, which can be DONE or CREATING . |
Dropping Constraints
A constraint can be dropped with the DROP CONSTRAINT
statement.
To drop a constraint named nn_1
:
DROP CONSTRAINT nn_1
Using the IF EXISTS Flag
The constraint deletion will fail and output an error message if the specified constraint name does not exist.
With the IF EXISTS
flag, no error message will be returned when the specified constraint name is not found, and no constraint is deleted.
To drop a constraint named nn
. If the constraint name does not exist, skip the deletion without returning an error message:
DROP CONSTRAINT nn_1 IF EXISTS
Restrictions on Properties with Constraints
Renaming Properties
Properties with the NOT NULL
constraints can be renamed. However, renaming properties with an EDGE KEY
constraint is not allowed.
Dropping Properties
A property with a constraint cannot be dropped until all the related constraints are deleted.