neo4j · rsill-neo4j · May 7, 2025 · May 6, 2025
diff --git a/modules/ROOT/pages/directives/autogeneration.adoc b/modules/ROOT/pages/directives/autogeneration.adoc
@@ -15,8 +15,6 @@ This enables autogeneration of IDs for the field.
 The format of each generated ID is a UUID generated by the link:https://neo4j.com/docs/cypher-manual/current/functions/scalar/#functions-randomuuid[`randomUUID()` function].
 The field will not be present in input types for mutations.
 
-It is recommended to use xref::/directives/indexes-and-constraints.adoc#_unique[`@unique`] in conjunction with this to add a unique node property constraint.
-
 === Definition
 
 [source, graphql, indent=0]

diff --git a/modules/ROOT/pages/directives/database-mapping.adoc b/modules/ROOT/pages/directives/database-mapping.adoc
@@ -111,17 +111,6 @@ Defining `labels` means you take control of the database labels of the node.
 Indexes and constraints in Neo4j only support a single label, for which the first element of the `labels` argument is used.
 ====
 
-The following example results in a unique constraint to be asserted for the label `K9` and the property `name`:
-
-[source, graphql, indent=0]
-----
-type Dog @node(labels: ["K9", "Dog"]) {
-    name: String! @unique
-}
-----
-
-See xref::/directives/indexes-and-constraints.adoc#_unique[`@unique`] to learn more about the `@unique` directive.
-
 
 ==== Using `$jwt` and `$context`
 

diff --git a/modules/ROOT/pages/directives/indexes-and-constraints.adoc b/modules/ROOT/pages/directives/indexes-and-constraints.adoc
@@ -165,94 +165,6 @@ query {
 ----
 
 
-== `@unique`
-
-=== Definition
-
-Unique node property constraints map to `@unique` directives used in your type definitions.
-They have the following definition:
-
-[source, graphql, indent=0]
-----
-"""Informs @neo4j/graphql that there should be a uniqueness constraint in the database for the decorated field."""
-directive @unique(
-    """The name which should be used for this constraint. By default; type name, followed by an underscore, followed by the field name."""
-    constraintName: String
-) on FIELD_DEFINITION
-----
-
-Using this directive does not automatically ensure the existence of these constraints.
-Run a function on server startup.
-See section xref::/directives/indexes-and-constraints.adoc#_asserting_constraints[Asserting constraints] for details.
-
-=== Usage
-
-`@unique` directives can only be used in GraphQL object types representing nodes, and they are only applicable for the "main" label for the node.
-
-In the following example, a unique constraint is asserted for the label `Colour` and the property `hexadecimal`:
-
-[source, graphql, indent=0]
-----
-type Colour @node {
-    hexadecimal: String! @unique
-}
-----
-
-In the next example, a unique constraint with name `unique_colour` is asserted for the label `Colour` and the property `hexadecimal`:
-
-[source, graphql, indent=0]
-----
-type Colour @node {
-    hexadecimal: String! @unique(constraintName: "unique_colour")
-}
-----
-
-The `@node` directive is used to change the database label mapping in this next example, so a unique constraint is asserted for the first label in the list, `Color`, and the property `hexadecimal`:
-
-[source, graphql, indent=0]
-----
-type Colour @node(labels: ["Color"]) {
-    hexadecimal: String! @unique
-}
-----
-
-In the following example, all labels specified in the `labels` argument of the `@node` directive are also checked when asserting constraints.
-If there is a unique constraint specified for the `hexadecimal` property of nodes with the `Hue` label, but not the `Color` label, no error is thrown and no new constraints are created when running `assertIndexesAndConstraints`.
-
-[source, graphql, indent=0]
-----
-type Colour @node(labels: ["Color", "Hue"]) {
-    hexadecimal: String! @unique
-}
-----
-
-== Asserting constraints
-
-In order to ensure that the specified constraints exist in the database, you need to run the function `assertIndexesAndConstraints`.
-A simple example to check for the existence of the necessary constraints might look like the following, assuming a valid driver instance in the variable `driver`. 
-This checks for the unique node property constraint for the field decorated `@unique`, and checks for the index specified in `@fulltext`:
-
-[source, javascript, indent=0]
-----
-const typeDefs = `#graphql
-    type Color @node {
-        id: ID! @id
-        hexadecimal: String! @unique
-    }
-
-    type Product @fulltext(indexes: [{ indexName: "ProductName", fields: ["name"] }]) @node {
-        name: String!
-        color: Color! @relationship(type: "OF_COLOR", direction: OUT)
-    }
-`;
-
-const neoSchema = new Neo4jGraphQL({ typeDefs, driver });
-
-const schema = await neoSchema.getSchema();
-
-await neoSchema.assertIndexesAndConstraints();
-----
-
 [#_vector_index_search]
 == `@vector`
 

diff --git a/modules/ROOT/pages/integrations/apollo-federation.adoc b/modules/ROOT/pages/integrations/apollo-federation.adoc
@@ -207,7 +207,7 @@ const typeDefs = `#graphql
 `;
 ----
 
-Although only the `@key` directive has been added to this example, consider using either the `@id` or the `@unique` directives on the `id` field.
+Although only the `@key` directive has been added to this example, consider using the `@id` directive on the `id` field.
 The Federation gateway expects each key to resolve to one result, so it is good practice to ensure that these values are unique in the database.
 
 == Generate a subgraph schema

diff --git a/modules/ROOT/pages/integrations/relay-compatibility.adoc b/modules/ROOT/pages/integrations/relay-compatibility.adoc
@@ -77,5 +77,4 @@ Also, the `Book` type is now refetchable via the `node` query field, and is read
 [WARNING]
 ====
 The `@relayId` directive does not guarantee uniqueness.
-You should configure a unique node property constraint using xref:directives/indexes-and-constraints.adoc[the `@unique` directive].
 ====