From a1ce1abfee6dd41d759d5f472f3552107529b779 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jens=20Pryce-=C3=85klundh?= <112686610+JPryce-Aklundh@users.noreply.github.com> Date: Fri, 30 May 2025 15:59:18 +0200 Subject: [PATCH] Fix broken anchors (#1290) --- .../appendix/gql-conformance/additional-cypher.adoc | 8 ++++---- modules/ROOT/pages/appendix/gql-conformance/index.adoc | 2 +- .../appendix/gql-conformance/supported-mandatory.adoc | 10 +++++----- modules/ROOT/pages/clauses/clause-composition.adoc | 2 +- modules/ROOT/pages/clauses/index.adoc | 2 +- modules/ROOT/pages/clauses/match.adoc | 2 +- modules/ROOT/pages/clauses/merge.adoc | 2 +- modules/ROOT/pages/constraints/syntax.adoc | 2 +- .../deprecations-additions-removals-compatibility.adoc | 8 ++++---- modules/ROOT/pages/expressions/map-expressions.adoc | 2 +- modules/ROOT/pages/expressions/string-operators.adoc | 2 +- modules/ROOT/pages/functions/index.adoc | 8 ++++---- modules/ROOT/pages/functions/list.adoc | 2 +- modules/ROOT/pages/functions/string.adoc | 2 +- modules/ROOT/pages/functions/vector.adoc | 4 ++-- .../search-performance-indexes/managing-indexes.adoc | 2 +- modules/ROOT/pages/indexes/syntax.adoc | 2 +- modules/ROOT/pages/patterns/non-linear-patterns.adoc | 1 + .../pages/planning-and-tuning/execution-plans.adoc | 2 +- .../pages/planning-and-tuning/operators/index.adoc | 4 ++-- modules/ROOT/pages/subqueries/collect.adoc | 2 +- modules/ROOT/pages/subqueries/count.adoc | 2 +- modules/ROOT/pages/subqueries/existential.adoc | 2 +- modules/ROOT/pages/syntax/parameters.adoc | 2 +- .../values-and-types/ordering-equality-comparison.adoc | 4 ++-- modules/ROOT/pages/values-and-types/spatial.adoc | 10 +++++----- 26 files changed, 46 insertions(+), 45 deletions(-) diff --git a/modules/ROOT/pages/appendix/gql-conformance/additional-cypher.adoc b/modules/ROOT/pages/appendix/gql-conformance/additional-cypher.adoc index 6bff1ceca..20fe2793b 100644 --- a/modules/ROOT/pages/appendix/gql-conformance/additional-cypher.adoc +++ b/modules/ROOT/pages/appendix/gql-conformance/additional-cypher.adoc @@ -72,10 +72,10 @@ Either the pattern already exists, or it needs to be created. | xref:expressions/list-expressions.adoc#list-comprehension[List comprehension] | Syntactic construct for creating a `LIST` based on existing lists. -| xref:values-and-types/maps.adoc#cypher-map-comprehension[Map projection] +| xref:expressions/map-expressions.adoc#map-projection[Map projection] | Constructs `MAP` projections from nodes, relationships, and other `MAP` values. -| xref:values-and-types/lists.adoc#cypher-pattern-comprehension[Pattern comprehension] +| xref:expressions/list-expressions.adoc#pattern-comprehension[Pattern comprehension] | Syntactic construct for creating a `LIST` based on matchings of a pattern. |=== @@ -389,12 +389,12 @@ It is only supported in the xref:clauses/use.adoc[`USE`] clause. | xref:functions/spatial.adoc#functions-point[`point()`] | Returns a 2D or 3D point object, given two or respectively three coordinate values in the Cartesian coordinate system or WGS 84 geographic coordinate system. -| xref:functions/spatial.adoc#functions-point-distance[`point.distance()`] +| xref:functions/spatial.adoc#functions-distance[`point.distance()`] | Returns a `FLOAT` representing the distance between any two points in the same CRS. If the points are in the WGS 84 CRS, the function returns the geodesic distance (i.e., the shortest path along the curved surface of the Earth). If the points are in a Cartesian CRS, the function returns the Euclidean distance (i.e., the shortest straight-line distance in a flat, planar space). -| xref:functions/spatial.adoc#functions-point-withinBBox[`point.withinBBox()`] +| xref:functions/spatial.adoc#functions-withinBBox[`point.withinBBox()`] | Returns true if the provided point is within the bounding box defined by the two provided points. |=== diff --git a/modules/ROOT/pages/appendix/gql-conformance/index.adoc b/modules/ROOT/pages/appendix/gql-conformance/index.adoc index 8a3bf4671..8e1f7a657 100644 --- a/modules/ROOT/pages/appendix/gql-conformance/index.adoc +++ b/modules/ROOT/pages/appendix/gql-conformance/index.adoc @@ -47,4 +47,4 @@ For more information, see xref:syntax/parsing.adoc#_using_unicodes_in_cypher[Par * Cypher supports the following mandatory GQL property types: `BOOLEAN` (`BOOL`), `FLOAT` footnote:[The `FLOAT` type in Cypher always represents a 64-bit double-precision floating point number.], `INTEGER` (`SIGNED INTEGER`, or `INT`)footnote:[The `INTEGER` type in Cypher always represents a 64-bit `INTEGER`.], and `STRING` (`VARCHAR`). + Cypher also supports the following optional GQL property types: `DATE`, `DURATION`, `LIST` (`ARRAY`, `INNER_TYPE LIST`, or `INNER_TYPE ARRAY`)footnote:[The `INNER_TYPE` cannot be a `LIST` type.], `LOCAL DATETIME` (`TIMESTAMP WITHOUT TIME ZONE`), `LOCAL TIME` (`TIME WITHOUT TIME ZONE`), `POINT`, `ZONED DATETIME` (`TIME WITH TIME ZONE`), and `ZONED TIME` (`TIMESTAMP WITH TIME ZONE`). -For more information, see xref:values-and-types/property-structural-constructed.adoc#_property_types[Values and types -> property types]. +For more information, see xref:values-and-types/property-structural-constructed.adoc#property-types[Values and types -> property types]. diff --git a/modules/ROOT/pages/appendix/gql-conformance/supported-mandatory.adoc b/modules/ROOT/pages/appendix/gql-conformance/supported-mandatory.adoc index e66435560..48b15e6c0 100644 --- a/modules/ROOT/pages/appendix/gql-conformance/supported-mandatory.adoc +++ b/modules/ROOT/pages/appendix/gql-conformance/supported-mandatory.adoc @@ -18,12 +18,12 @@ The below table is instead listed in order of their appearance in the link:https | 4.13 | GQL object types -| xref:values-and-types/property-structural-constructed.adoc#structural-types[Structural types], xref:values-and-types/property-structural-constructed.adoc#type-synonyms[Types and their synonyms]. +| xref:values-and-types/property-structural-constructed.adoc#structural-types[Structural types], xref:values-and-types/property-structural-constructed.adoc#types-synonyms[Types and their synonyms]. | Includes: `NODE` (`ANY NODE`, `VERTEX`, `ANY VERTEX`) and `RELATIONSHIP` (`ANY RELATIONSHIP`, `EDGE`, `ANY EDGE`). | 4.16 | Predefined value types -| xref:values-and-types/property-structural-constructed.adoc#property-types[Property types], xref:values-and-types/property-structural-constructed.adoc#type-synonyms[Types and their synonyms]. +| xref:values-and-types/property-structural-constructed.adoc#property-types[Property types], xref:values-and-types/property-structural-constructed.adoc#types-synonyms[Types and their synonyms]. | Includes: `BOOLEAN` (`BOOL`), `FLOAT`, `INTEGER` (`SIGNED INTEGER`, `INT`), and `STRING` (`VARCHAR`). Cypher supports the boolean type predicate for `true`, `false`, and `null` but does not support the GQL keyword `UNKNOWN`. @@ -122,7 +122,7 @@ The only way to guarantee row order in Neo4j is to use xref:clauses/order-by.ado | 16.17 | -| xref:clauses/order-by.adoc#order-nodes-in-descending-order[Order results in ascending or descending order] +| xref:clauses/order-by.adoc#ascending-descending-order[Ascending and descending order] | | 16.19 @@ -137,7 +137,7 @@ The only way to guarantee row order in Neo4j is to use xref:clauses/order-by.ado | 19.4 | -| xref:functions/predicate.adoc#function-exists[`exists()`] +| xref:functions/predicate.adoc#functions-exists[`exists()`] | | 19.5 @@ -173,7 +173,7 @@ In Cypher, current user details can be seen using the link:{neo4j-docs-base-uri} | 20.9 | -| xref:functions/aggregating.adoc#functions-avg[`avg()`], xref:functions/aggregating.adoc#functions-count[`count()`], xref:functions/aggregating.adoc#functions-max[`max`], xref:functions/aggregating.adoc#functions-mind[`min()`], xref:functions/aggregating.adoc#functions-sum[`sum()`] +| xref:functions/aggregating.adoc#functions-avg[`avg()`], xref:functions/aggregating.adoc#functions-count[`count()`], xref:functions/aggregating.adoc#functions-max[`max`], xref:functions/aggregating.adoc#functions-min[`min()`], xref:functions/aggregating.adoc#functions-sum[`sum()`] | Cypher and GQL handle `null` values differently for the `sum()` function when queries return 0 rows. For example, `RETURN sum()` on an empty table returns `null` in GQL, but in Cypher it returns `0`. diff --git a/modules/ROOT/pages/clauses/clause-composition.adoc b/modules/ROOT/pages/clauses/clause-composition.adoc index 012cdad48..23769cc64 100644 --- a/modules/ROOT/pages/clauses/clause-composition.adoc +++ b/modules/ROOT/pages/clauses/clause-composition.adoc @@ -974,7 +974,7 @@ materialize the table of intermediate results before executing the next clause. This approach would consume a lot of memory for materializing the tables of intermediate results and would generally not perform well. Instead, Cypher will in general try to interleave the execution of clauses. -This is called xref::planning-and-tuning/execution-plans.adoc#laze-eager-evaluation[lazy evaluation]. +This is called xref::planning-and-tuning/execution-plans.adoc#lazy-eager-evaluation[lazy evaluation]. It only materializes intermediate results when needed. In many read-write queries it is unproblematic to execute clauses interleaved, but when it is not, Cypher must ensure that the table of intermediate results gets materialized at the right time(s). diff --git a/modules/ROOT/pages/clauses/index.adoc b/modules/ROOT/pages/clauses/index.adoc index a7cdfb28b..d0930a5b9 100644 --- a/modules/ROOT/pages/clauses/index.adoc +++ b/modules/ROOT/pages/clauses/index.adoc @@ -275,7 +275,7 @@ These comprise clauses to create, show, and drop indexes and constraints. |=== | Clause | Description -m| xref:indexes/search-performance-indexes/managing-indexes.adoc#indexes-syntax[CREATE \| SHOW \| DROP INDEX] +m| xref:indexes/syntax.adoc[CREATE \| SHOW \| DROP INDEX] | Create, show or drop an index. m| xref::constraints/syntax.adoc[CREATE \| SHOW \| DROP CONSTRAINT] diff --git a/modules/ROOT/pages/clauses/match.adoc b/modules/ROOT/pages/clauses/match.adoc index d8eb85016..14f5cd52c 100644 --- a/modules/ROOT/pages/clauses/match.adoc +++ b/modules/ROOT/pages/clauses/match.adoc @@ -147,7 +147,7 @@ For a list of all label expressions supported by Cypher, see xref:patterns/refer The `MATCH` clause allows you to specify relationship patterns of varying complexity to retrieve from a graph. Unlike a node pattern, a relationship pattern cannot be used in a `MATCH` clause without node patterns at both ends. -For more information about relationship patterns, see xref:patterns/fixed-length-patterns#relationship patterns[Patterns -> Relationship patterns]. +For more information about relationship patterns, see xref:patterns/fixed-length-patterns#relationship-patterns[Patterns -> Relationship patterns]. [NOTE] Relationships will only be matched once inside a single pattern. diff --git a/modules/ROOT/pages/clauses/merge.adoc b/modules/ROOT/pages/clauses/merge.adoc index 61fa47b6c..53e7c621b 100644 --- a/modules/ROOT/pages/clauses/merge.adoc +++ b/modules/ROOT/pages/clauses/merge.adoc @@ -422,7 +422,7 @@ Instead, a new `Movie` node is created. === Merge on an undirected relationship `MERGE` can also be used without specifying the direction of a relationship. -Cypher will first try to xref:clauses/match.adoc#_match_on_an_undirected_relationship[match the relationship in both directions]. +Cypher will first try to match the relationship in both directions. If the relationship does not exist in either direction, it will create one left to right. .Query diff --git a/modules/ROOT/pages/constraints/syntax.adoc b/modules/ROOT/pages/constraints/syntax.adoc index fcb83e9dc..e85ed9854 100644 --- a/modules/ROOT/pages/constraints/syntax.adoc +++ b/modules/ROOT/pages/constraints/syntax.adoc @@ -137,7 +137,7 @@ Where `` is one of the following property types: Allowed syntax variations of these types are listed in xref::values-and-types/property-structural-constructed.adoc#types-synonyms[Types and their synonyms]. -For examples on how to create property type constraints, see xref:constraints/managing-constraints.adoc#create-property-type-constraint[Create, show, and drop constraints -> Create property type constraints]. +For examples on how to create property type constraints, see xref:constraints/managing-constraints.adoc#create-property-type-constraints[Create, show, and drop constraints -> Create property type constraints]. [role=label--enterprise-edition] diff --git a/modules/ROOT/pages/deprecations-additions-removals-compatibility.adoc b/modules/ROOT/pages/deprecations-additions-removals-compatibility.adoc index d5e8e7ddb..97e72a32b 100644 --- a/modules/ROOT/pages/deprecations-additions-removals-compatibility.adoc +++ b/modules/ROOT/pages/deprecations-additions-removals-compatibility.adoc @@ -814,7 +814,7 @@ label:new[] SET n:$(label) REMOVE n:$(label) ---- -| Added the ability to dynamically reference labels in xref:clauses/set.adoc#set-set-a-dynamic-label-on-a-node[SET] and xref:clauses/remove.adoc#remove-remove-a-label-dynamically-from-a-node[REMOVE] clauses. +| Added the ability to dynamically reference labels in xref:clauses/set.adoc#dynamic-set-node-label[SET] and xref:clauses/remove.adoc#dynamic-remove-node-label[REMOVE] clauses. a| label:functionality[] @@ -1400,7 +1400,7 @@ IS [NOT] [NFC \| NFD \| NFKC \| NFKD] NORMALIZED RETURN "string" IS NORMALIZED ---- -| Introduction of an xref::expressions/predicates/string-operators.adoc#string-normalization-operator[IS NORMALIZED] operator. +| Introduction of an xref::expressions/predicates/string-operators.adoc#string-normalization-operators[IS NORMALIZED] operator. The operator can be used to check if a `STRING` is normalized according to the specified normalization form, which can be of type `NFC`, `NFD`, `NFKC`, or `NFKD`. a| @@ -1553,7 +1553,7 @@ label:updated[] SHOW VECTOR INDEXES ---- -| Extended xref:indexes/search-performance-indexes/managing-indexes.adoc#indexes-list-indexes[`SHOW INDEXES`] with easy filtering for vector indexes. +| Extended xref:indexes/semantic-indexes/vector-indexes.adoc#show-vector-indexes[`SHOW INDEXES`] with easy filtering for vector indexes. This is equivalent to `SHOW INDEXES WHERE type = 'VECTOR'`. a| @@ -2260,7 +2260,7 @@ CREATE CONSTRAINT name FOR ()-[r:TYPE]-() REQUIRE r.prop IS RELATIONSHIP KEY ---- a| -Added relationship xref:constraints/managing-constraints.adoc#create-key-constraint[key] and xref:constraints/managing-constraints.adoc#create--property-uniqueness-constraint[property uniqueness] constraints. +Added relationship xref:constraints/managing-constraints.adoc#create-key-constraints[key] and xref:constraints/managing-constraints.adoc#create-property-uniqueness-constraints[property uniqueness] constraints. a| label:functionality[] diff --git a/modules/ROOT/pages/expressions/map-expressions.adoc b/modules/ROOT/pages/expressions/map-expressions.adoc index 9eb94e695..4a76e363a 100644 --- a/modules/ROOT/pages/expressions/map-expressions.adoc +++ b/modules/ROOT/pages/expressions/map-expressions.adoc @@ -297,7 +297,7 @@ RETURN map{.a, .c} AS projectedMap 1+d|Rows: 1 |=== -In the below query, a map projection with property selectors is used to xref:functions/list.adoc#functions-collect[`collect`] only the `title` and `release` year of each movie. +In the below query, a map projection with property selectors is used to xref:functions/aggregating.adoc#functions-collect[`collect`] only the `title` and `release` year of each movie. .Map projection with a key selector [source, cypher] diff --git a/modules/ROOT/pages/expressions/string-operators.adoc b/modules/ROOT/pages/expressions/string-operators.adoc index 530da2389..09764fa95 100644 --- a/modules/ROOT/pages/expressions/string-operators.adoc +++ b/modules/ROOT/pages/expressions/string-operators.adoc @@ -151,7 +151,7 @@ RETURN reduce(acc = '', item IN list| acc || item) AS result 1+d| Rows: 1 |=== -The following query uses the xref:functions/scalar.adoc#functions-head[`head()`] function to start the accumulator with the first `item` in the `list`, while the xref:functions/scalar.adoc#functions-tail[`tail()`] function returns the remaining items in the `list`. +The following query uses the xref:functions/scalar.adoc#functions-head[`head()`] function to start the accumulator with the first `item` in the `list`, while the xref:functions/list.adoc#functions-tail[`tail()`] function returns the remaining items in the `list`. The `reduce()` function then concatenates these items with commas. .Add prefix and a separator (`,`) in a `STRING` concatenated from `STRING` values in a `LIST` diff --git a/modules/ROOT/pages/functions/index.adoc b/modules/ROOT/pages/functions/index.adoc index 4a692e808..73eebb482 100644 --- a/modules/ROOT/pages/functions/index.adoc +++ b/modules/ROOT/pages/functions/index.adoc @@ -591,7 +591,7 @@ These functions are used to specify 2D or 3D points in a geographic or cartesian |=== | Function | Signature | Description -1.1+| xref::functions/spatial.adoc#functions-point-cartesian-2d[`point()`] +1.1+| xref::functions/spatial.adoc#functions-point[`point()`] | `point(input :: MAP) :: POINT` | Returns a 2D or 3D point object, given two or respectively three coordinate values in the Cartesian coordinate system or WGS 84 geographic coordinate system. @@ -617,7 +617,7 @@ If the points are in a Cartesian CRS, the function returns the Euclidean distanc |=== | Function | Signature | Description -1.1+| xref::functions/temporal/duration.adoc#functions-duration[`duration()`] +1.1+| xref::functions/temporal/duration.adoc#functions-durations[`duration()`] | `duration(input :: ANY) :: DURATION` | Constructs a `DURATION` value. @@ -672,11 +672,11 @@ Values of the xref::values-and-types/temporal.adoc[temporal types] -- `DATE`, `Z | `datetime(input = DEFAULT_TEMPORAL_ARGUMENT :: ANY) :: ZONED DATETIME` | Creates a `ZONED DATETIME` instant. -1.1+| xref::functions/temporal/index.adoc#functions-datetime-timestamp[`datetime.fromEpoch()`] +1.1+| xref::functions/temporal/index.adoc#functions-datetime-fromepoch[`datetime.fromEpoch()`] | `datetime.fromEpoch(seconds :: INTEGER \| FLOAT, nanoseconds :: INTEGER \| FLOAT) :: ZONED DATETIME` | Creates a `ZONED DATETIME` given the seconds and nanoseconds since the start of the epoch. -1.1+| xref::functions/temporal/index.adoc#functions-datetime-timestamp[`datetime.fromEpochMillis()`] +1.1+| xref::functions/temporal/index.adoc#functions-datetime-fromepochmillis[`datetime.fromEpochMillis()`] | `datetime.fromEpochMillis(milliseconds :: INTEGER \| FLOAT) :: ZONED DATETIME` | Creates a `ZONED DATETIME` given the milliseconds since the start of the epoch. diff --git a/modules/ROOT/pages/functions/list.adoc b/modules/ROOT/pages/functions/list.adoc index d66b4329d..b545d5ba7 100644 --- a/modules/ROOT/pages/functions/list.adoc +++ b/modules/ROOT/pages/functions/list.adoc @@ -345,7 +345,7 @@ A `LIST` containing all the `RELATIONSHIP` values in the `PATH` `p |=== | Any `null` element in `original` is preserved. -| See also xref:functions/string.adoc#functions-reverse[String functions -> reverse]. +| See also xref:functions/string.adoc#functions-reverse[String functions -> `reverse()`]. |=== diff --git a/modules/ROOT/pages/functions/string.adoc b/modules/ROOT/pages/functions/string.adoc index 4f71cb9a9..c6e2fa13b 100644 --- a/modules/ROOT/pages/functions/string.adoc +++ b/modules/ROOT/pages/functions/string.adoc @@ -401,7 +401,7 @@ RETURN replace("hello", "l", "w", 1) |=== | `reverse(null)` returns `null`. -| See also xref:functions/list.adoc#functions-reverse[List functions -> reverse]. +| See also xref:functions/list.adoc#functions-reverse-list[List functions -> `reverse()`]. |=== diff --git a/modules/ROOT/pages/functions/vector.adoc b/modules/ROOT/pages/functions/vector.adoc index 49a8a75f7..8927aba94 100644 --- a/modules/ROOT/pages/functions/vector.adoc +++ b/modules/ROOT/pages/functions/vector.adoc @@ -32,7 +32,7 @@ For more details, see the {link-vector-indexes}#similarity-functions[vector inde | `vector.similarity.cosine(null, b)` returns `null`. | `vector.similarity.cosine(a, null)` returns `null`. | Both vectors must be of the same dimension. -| Both vectors must be {link-vector-indexes}#indexes-vector-similarity-cosine[*valid*] with respect to cosine similarity. +| Both vectors must be {link-vector-indexes}#similarity-functions[*valid*] with respect to cosine similarity. | The implementation is identical to that of the latest available vector index provider (`vector-2.0`). | `vector.similarity.cosine()` returns the neighborhood of nodes along with their respective cosine similarity scores, sorted in descending order of similarity. The similarity score range from `0` and `1`, with scores closer to `1` indicating a higher degree of similarity between the indexed vector and the query vector. @@ -62,7 +62,7 @@ For more details, see the {link-vector-indexes}#similarity-functions[vector inde | `vector.similarity.euclidean(null, b)` returns `null`. | `vector.similarity.euclidean(a, null)` returns `null`. | Both vectors must be of the same dimension. -| Both vectors must be {link-vector-indexes}#indexes-vector-similarity-euclidean[*valid*] with respect to Euclidean similarity. +| Both vectors must be {link-vector-indexes}#similarity-functions[*valid*] with respect to Euclidean similarity. | The implementation is identical to that of the latest available vector index provider (`vector-2.0`). | `vector.similarity.euclidean()` returns the neighborhood of nodes along with their respective Euclidean similarity scores, sorted in descending order of similarity. The similarity score range from `0` and `1`, with scores closer to `1` indicating a higher degree of similarity between the indexed vector and the query vector. diff --git a/modules/ROOT/pages/indexes/search-performance-indexes/managing-indexes.adoc b/modules/ROOT/pages/indexes/search-performance-indexes/managing-indexes.adoc index 184c0f7d3..b2c7fca61 100644 --- a/modules/ROOT/pages/indexes/search-performance-indexes/managing-indexes.adoc +++ b/modules/ROOT/pages/indexes/search-performance-indexes/managing-indexes.adoc @@ -417,7 +417,7 @@ point.distance(n.prop, center) < = distance |=== The above set of predicates can be extended with the use of type constraints. -See xref:indexes/search-performance-indexes/using-indexes.adoc#index-compatibility-type-constraints[Index compatibility and type constraints] for more information. +See xref:indexes/search-performance-indexes/using-indexes.adoc#type-constraints[The impact of indexes on query performances -> Property type constraints] for more information. [TIP] To learn more about the spatial data types supported by Cypher, see the page about xref:values-and-types/spatial.adoc[Spatial values]. diff --git a/modules/ROOT/pages/indexes/syntax.adoc b/modules/ROOT/pages/indexes/syntax.adoc index c121708d8..82e83035c 100644 --- a/modules/ROOT/pages/indexes/syntax.adoc +++ b/modules/ROOT/pages/indexes/syntax.adoc @@ -290,7 +290,7 @@ CALL db.index.vector.queryRelationships(indexName :: STRING, numberOfNearestNeig The `numberOfNearestNeighbours` refers to the number of nearest neighbors to return as the neighborhood. The `query` vector refers to the `LIST` in which to search for the neighborhood. -For more information, see xref:indexes/semantic-indexes/vector-indexes.adoc#indexes-vector-query[Vector indexes - Query vector indexes]. +For more information, see xref:indexes/semantic-indexes/vector-indexes.adoc#query-vector-index[Vector indexes - Query vector indexes]. [[drop-index]] == DROP INDEX diff --git a/modules/ROOT/pages/patterns/non-linear-patterns.adoc b/modules/ROOT/pages/patterns/non-linear-patterns.adoc index 595dc307e..c901e0fb3 100644 --- a/modules/ROOT/pages/patterns/non-linear-patterns.adoc +++ b/modules/ROOT/pages/patterns/non-linear-patterns.adoc @@ -3,6 +3,7 @@ Cypher can be used to express non-linear patterns, either by equijoins (an operation in which more than one node relationship in a path is the same) or by more complicated graph patterns consisting of multiple path patterns. +[[equijoins]] == Equijoins An equijoin is an operation on paths that requires more than one of the nodes or relationships of the paths to be the same. diff --git a/modules/ROOT/pages/planning-and-tuning/execution-plans.adoc b/modules/ROOT/pages/planning-and-tuning/execution-plans.adoc index ec6c0cb5c..f664542b5 100644 --- a/modules/ROOT/pages/planning-and-tuning/execution-plans.adoc +++ b/modules/ROOT/pages/planning-and-tuning/execution-plans.adoc @@ -54,7 +54,7 @@ CREATE (pmr:Station {name: 'Peckham Rye'}), (s7)-[:NEXT {distance: 1.4}]->(s6) ---- -The example query uses a xref:patterns/variable-length-patterns.adoc#quantified-path-pattern[quantified path pattern] to count the number of possible path patterns between the start `Station`, `Denmark Hill`, and the end `Station`, `Clapham Junction`: +The example query uses a xref:patterns/variable-length-patterns.adoc#quantified-path-patterns[quantified path pattern] to count the number of possible path patterns between the start `Station`, `Denmark Hill`, and the end `Station`, `Clapham Junction`: .Query [source, cypher] diff --git a/modules/ROOT/pages/planning-and-tuning/operators/index.adoc b/modules/ROOT/pages/planning-and-tuning/operators/index.adoc index 3fabf028b..570199b37 100644 --- a/modules/ROOT/pages/planning-and-tuning/operators/index.adoc +++ b/modules/ROOT/pages/planning-and-tuning/operators/index.adoc @@ -338,7 +338,7 @@ Tests for the presence of a pattern predicate in queries containing multiple pat | | -| xref::planning-and-tuning/operators/operators-detail.adoc#query-plan-node-by-element-id-seek[NodeByElementIdSeek] +| xref::planning-and-tuning/operators/operators-detail.adoc#query-plan-node-by-elementid-seek[NodeByElementIdSeek] | Reads one or more nodes by id from the node store, specified via the function xref::functions/scalar.adoc#functions-elementid[elementId()]. | label:yes[] | @@ -926,7 +926,7 @@ As the direction is unspecified, two rows are produced for each relationship as | | -| xref::planning-and-tuning/operators/operators-detail.adoc#query-plan-varlength-expand-pruning-bfs[VarLengthExpand(Pruning,BFS)] +| xref::planning-and-tuning/operators/operators-detail.adoc#query-plan-breadth-first-varlength-expand-pruning-bfs-all[VarLengthExpand(Pruning,BFS)] | Traverses variable-length relationships from a given node and only returns unique end nodes. | | diff --git a/modules/ROOT/pages/subqueries/collect.adoc b/modules/ROOT/pages/subqueries/collect.adoc index 714ec9298..baf50c305 100644 --- a/modules/ROOT/pages/subqueries/collect.adoc +++ b/modules/ROOT/pages/subqueries/collect.adoc @@ -31,7 +31,7 @@ CREATE == Simple `COLLECT` subquery Variables introduced by the outside scope can be used in the `COLLECT` subquery without importing them. -In this regard, `COLLECT` subqueries are different from `CALL` subqueries, xref::subqueries/call-subquery.adoc#call-importing-variables[which do require importing]. +In this regard, `COLLECT` subqueries are different from `CALL` subqueries, xref::subqueries/call-subquery.adoc#import-variables[which do require importing]. The following query exemplifies this and outputs the owners of the dog named `Ozzy`: [source, cypher] diff --git a/modules/ROOT/pages/subqueries/count.adoc b/modules/ROOT/pages/subqueries/count.adoc index 2b6ec4d05..ec4ec9bd4 100644 --- a/modules/ROOT/pages/subqueries/count.adoc +++ b/modules/ROOT/pages/subqueries/count.adoc @@ -28,7 +28,7 @@ CREATE == Simple `COUNT` subquery Variables introduced by the outside scope can be used in the `COUNT` subquery without importing them. -In this regard, `COUNT` subqueries are different from `CALL` subqueries, xref::subqueries/call-subquery.adoc#call-importing-variables[which do require importing]. +In this regard, `COUNT` subqueries are different from `CALL` subqueries, xref::subqueries/call-subquery.adoc#import-variables[which do require importing]. The following query exemplifies this and outputs the owners of more than one dog: diff --git a/modules/ROOT/pages/subqueries/existential.adoc b/modules/ROOT/pages/subqueries/existential.adoc index e0132177e..fa6678474 100644 --- a/modules/ROOT/pages/subqueries/existential.adoc +++ b/modules/ROOT/pages/subqueries/existential.adoc @@ -29,7 +29,7 @@ CREATE == Simple `EXISTS` subquery Variables introduced by the outside scope can be used in the `EXISTS` subquery without importing them. -In this regard, `EXISTS` subqueries are different from `CALL` subqueries, xref::subqueries/call-subquery.adoc#call-importing-variables[which do require importing]. +In this regard, `EXISTS` subqueries are different from `CALL` subqueries, xref::subqueries/call-subquery.adoc#import-variables[which do require importing]. The following example shows this: diff --git a/modules/ROOT/pages/syntax/parameters.adoc b/modules/ROOT/pages/syntax/parameters.adoc index c53fb01f3..2ffe9de69 100644 --- a/modules/ROOT/pages/syntax/parameters.adoc +++ b/modules/ROOT/pages/syntax/parameters.adoc @@ -17,7 +17,7 @@ Parameters can be used for: * Literals and expressions. * Node and relationship ids. -* Properties, when referenced dynamically (for more information, see xref:clauses/where.adoc#filter-on-dynamic-property[Filter on dynamically-computed node property]). +* Properties, when referenced dynamically (for more information, see xref:clauses/where.adoc#filter-on-dynamic-properties[`WHERE` -> Filter on dynamic properties]). * Node labels and relationship types, when referenced dynamically (for more information, see xref:clauses/match.adoc#dynamic-match[`MATCH` using dynamic node labels and relationship types]). Parameters cannot be used for the following constructs, as these form part of the query structure that is compiled into a query plan: diff --git a/modules/ROOT/pages/values-and-types/ordering-equality-comparison.adoc b/modules/ROOT/pages/values-and-types/ordering-equality-comparison.adoc index 8ec18d90b..e17d62dc1 100644 --- a/modules/ROOT/pages/values-and-types/ordering-equality-comparison.adoc +++ b/modules/ROOT/pages/values-and-types/ordering-equality-comparison.adoc @@ -36,7 +36,7 @@ For example, `1 > b` and `1 < b` are both `false` when `b` is NaN. * Boolean values are compared for ordering such that `false < true`. * When comparing values for ordering, if one of the arguments is `null`, the result is always `null`. * xref:values-and-types/spatial.adoc[Spatial values] cannot be compared using the operators `\<=`, `<`,`>=`, `>`. -To compare spatial values within a specific range, use either the xref:functions/spatial.adoc#functions-withinBBox[`point.withinBBox()`] or the xref:functions/spatial.adoc#functions-point-wgs84-2d[`point()`] function. +To compare spatial values within a specific range, use either the xref:functions/spatial.adoc#functions-withinBBox[`point.withinBBox()`] or the xref:functions/spatial.adoc#functions-point[`point()`] function. [[value-hierarchy]] === Hierarchy of values @@ -117,7 +117,7 @@ The following applies to the ordering of xref:values-and-types/spatial.adoc[spat * `POINT` values are ordered after lists and before temporal types. * `POINT` values of different coordinate reference systems (CRS) are ordered by the CRS code (the value of SRID field). -For the currently supported set of xref::values-and-types/spatial.adoc#cypher-spatial-crs[CRS], the following ascending order applies: `4326`, `4979`, `7302`, `9157`. +For the supported set of xref::values-and-types/spatial.adoc#spatial-values-crs-geographic[CRS], the following ascending order applies: `4326`, `4979`, `7302`, `9157`. * `POINT` values with the same CRS are ordered by each coordinate value in turn; first `x`, then `y`, and finally `z`. * Note that this ordering is different to the order returned by the spatial index, which follows the space filling curve. diff --git a/modules/ROOT/pages/values-and-types/spatial.adoc b/modules/ROOT/pages/values-and-types/spatial.adoc index d61959c0d..a115d692e 100644 --- a/modules/ROOT/pages/values-and-types/spatial.adoc +++ b/modules/ROOT/pages/values-and-types/spatial.adoc @@ -27,7 +27,7 @@ Values with the `POINT` type have the following characteristics: This means it contains either 2 or 3 64-bit `FLOAT` values, which together are called the _Coordinate_. * Each point will also be associated with a specific xref::values-and-types/spatial.adoc#spatial-values-crs[Coordinate Reference System] (CRS) that determines the meaning of the values in the _Coordinate_. * Instances of `POINT` and `LIST` can be assigned to node and relationship properties. -* Nodes and relationships with `POINT` or `LIST` properties can be indexed using a xref:indexes/search-performance-indexes/managing-indexes.adoc#indexes-create-a-node-point-index[point index]. +* Nodes and relationships with `POINT` or `LIST` properties can be indexed using a xref:indexes/search-performance-indexes/managing-indexes.adoc#create-point-index[point index]. This is true for all CRSs (and for both 2D and 3D). * The xref::functions/spatial.adoc#functions-distance[distance function] will work on points in all CRS and in both 2D and 3D, but only if the two points have the same CRS (and therefore also same dimension). @@ -52,12 +52,12 @@ Two Geographic Coordinate Reference Systems (CRS) are supported, modeling points ** A 2D geographic point in the _WGS 84_ CRS is specified in one of two ways: *** `longitude` and `latitude` (if these are specified, and the `crs` is not, then the `crs` is assumed to be `WGS-84`). *** `x` and `y` (in this case the `crs` must be specified, or will be assumed to be Cartesian). - ** Specifying this CRS can be done using either the name 'wgs-84' or the SRID 4326 as described in xref::functions/spatial.adoc#functions-point-wgs84-2d[point() - WGS 84 2D]. + ** Specifying this CRS can be done using either the name 'wgs-84' or the SRID 4326 as described in xref::functions/spatial.adoc#functions-point[point() - WGS 84 2D]. * link:https://spatialreference.org/ref/epsg/4979/[WGS 84 3D] ** A 3D geographic point in the _WGS 84_ CRS is specified one of in two ways: *** `longitude`, `latitude` and either `height` or `z` (if these are specified, and the `crs` is not, then the `crs` is assumed to be `WGS-84-3D`). *** `x`, `y` and `z` (in this case the `crs` must be specified, or will be assumed to be Cartesian-3D). - ** Specifying this CRS can be done using either the name 'wgs-84-3d' or the SRID 4979 as described in xref::functions/spatial.adoc#functions-point-wgs84-3d[point() - WGS 84 3D]. + ** Specifying this CRS can be done using either the name 'wgs-84-3d' or the SRID 4979 as described in xref::functions/spatial.adoc#functions-point[point() - WGS 84 3D]. [[spatial-values-converting-coordinates]] === Converting coordinate units @@ -97,10 +97,10 @@ Two Cartesian Coordinate Reference Systems (CRS) are supported, modeling points * *Cartesian 2D* ** A 2D point in the _Cartesian_ CRS is specified with a map containing `x` and `y` coordinate values - ** Specifying this CRS can be done using either the name 'cartesian' or the SRID 7203 as described in xref::functions/spatial.adoc#functions-point-cartesian-2d[point() - Cartesian 2D] + ** Specifying this CRS can be done using either the name 'cartesian' or the SRID 7203 as described in xref::functions/spatial.adoc#functions-point[point() - Cartesian 2D] * *Cartesian 3D* ** A 3D point in the _Cartesian_ CRS is specified with a map containing `x`, `y` and `z` coordinate values - ** Specifying this CRS can be done using either the name 'cartesian-3d' or the SRID 9157 as described in xref::functions/spatial.adoc#functions-point-cartesian-3d[point() - Cartesian 3D)] + ** Specifying this CRS can be done using either the name 'cartesian-3d' or the SRID 9157 as described in xref::functions/spatial.adoc#functions-point[point() - Cartesian 3D)] The units of the `x`, `y`, and `z` fields are unspecified. This means that when two Cartesian points are passed to the `distance` function, the resulting value will be in the same units as the original coordinates.