From f672cd13ef2ab96b9cdf04a3bcf5a8b279dca757 Mon Sep 17 00:00:00 2001 From: Simran Spiller Date: Wed, 8 Oct 2025 14:36:00 +0200 Subject: [PATCH 1/5] Release notes --- site/content/3.12/aql/graphs/traversals.md | 6 +++ .../version-3.12/whats-new-in-3-12.md | 42 +++++++++++++++++++ 2 files changed, 48 insertions(+) diff --git a/site/content/3.12/aql/graphs/traversals.md b/site/content/3.12/aql/graphs/traversals.md index d6ae7e2eeb..34ed71ea42 100644 --- a/site/content/3.12/aql/graphs/traversals.md +++ b/site/content/3.12/aql/graphs/traversals.md @@ -346,6 +346,12 @@ Use the [`WITH` statement](../high-level-operations/with.md) to specify the coll expect to be involved. This is required for traversals using collection sets in cluster deployments. +{{< tip >}} +From v3.12.6 onward, vertex collections are automatically deduced for graph +queries using collection sets / anonymous graphs if there is a named graph with +a matching edge collection in its edge definitions. +{{< /tio >}} + ## Pruning You can define stop conditions for graph traversals to return specific data and diff --git a/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md b/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md index 9dc4aee978..ff9f44244e 100644 --- a/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md +++ b/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md @@ -1293,6 +1293,48 @@ Indexes used: 10 idx_1836452431376941056 persistent coll ``` +### Deduction of node collection for graph queries + +Introduced in: v3.12.6 + +AQL graph traversals and path searches using anonymous graphs / collection sets +require that you declare all involved node collections upfront for cluster +deployments. That is, you need to use the `WITH` operation to list the collections +edges may point to, as well as the start vertex collection if not declared +otherwise. This also applies to single servers if the `--query.require-with` +startup option is enabled for parity between both deployment modes. + +For example, the node collection of the start vertex is `person` and the edges +stored in the `acts_in` edge collection point to a `movie` node collection. +Both need to be declared at the beginning of the query: + +```aql +WITH person, movie +FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in + RETURN v.label +``` + +From v3.12.6 onward, the vertex collections can be automatically inferred if +there is a named graph using the same edge collection(s) or if you use +`OPTIONS { vertexCollections: ... }` in queries to restrict which +node collections a traversal may visit. + +For example, assume there is a named graph that includes an edge definition for +the `acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection. If you now specify `acts_in` as an edge collection in +an anonymous graph query, all named graphs are checked for this edge collection, +and if there is a matching edge definition, its node collections are automatically +added as data sources to the query. You no longer have to manually declare the +`person` and `movie` collections: + +```aql +FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in + RETURN v.label +``` + +You can still declare collections manually, in which case they are also added +as data sources in addition to automatically deduced collections. + ## Indexing ### Multi-dimensional indexes From 8e61a614003615b5351455411112ee392581960d Mon Sep 17 00:00:00 2001 From: Simran Spiller Date: Tue, 14 Oct 2025 15:42:03 +0200 Subject: [PATCH 2/5] Fix typo --- site/content/3.12/aql/graphs/traversals.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/content/3.12/aql/graphs/traversals.md b/site/content/3.12/aql/graphs/traversals.md index 34ed71ea42..2f9d5dc699 100644 --- a/site/content/3.12/aql/graphs/traversals.md +++ b/site/content/3.12/aql/graphs/traversals.md @@ -350,7 +350,7 @@ in cluster deployments. From v3.12.6 onward, vertex collections are automatically deduced for graph queries using collection sets / anonymous graphs if there is a named graph with a matching edge collection in its edge definitions. -{{< /tio >}} +{{< /tip >}} ## Pruning From 297ef6c61d015b830db9f8bdd9ce38478a344c75 Mon Sep 17 00:00:00 2001 From: Simran Spiller Date: Wed, 15 Oct 2025 14:25:03 +0200 Subject: [PATCH 3/5] Remove mention of vertexCollections and add section about graph queries in cluster for path searches --- .../3.12/aql/graphs/all-shortest-paths.md | 50 +++++++++++++++++ site/content/3.12/aql/graphs/k-paths.md | 51 +++++++++++++++++ .../3.12/aql/graphs/k-shortest-paths.md | 51 +++++++++++++++++ site/content/3.12/aql/graphs/shortest-path.md | 48 ++++++++++++++++ site/content/3.12/aql/graphs/traversals.md | 43 +++++++++++++-- .../version-3.12/whats-new-in-3-12.md | 20 +++---- .../3.13/aql/graphs/all-shortest-paths.md | 52 ++++++++++++++++++ site/content/3.13/aql/graphs/k-paths.md | 53 ++++++++++++++++++ .../3.13/aql/graphs/k-shortest-paths.md | 53 ++++++++++++++++++ site/content/3.13/aql/graphs/shortest-path.md | 50 +++++++++++++++++ site/content/3.13/aql/graphs/traversals.md | 55 +++++++++++++++++-- .../version-3.12/whats-new-in-3-12.md | 42 ++++++++++++++ 12 files changed, 548 insertions(+), 20 deletions(-) diff --git a/site/content/3.12/aql/graphs/all-shortest-paths.md b/site/content/3.12/aql/graphs/all-shortest-paths.md index 69c770af05..6f552b0fa7 100644 --- a/site/content/3.12/aql/graphs/all-shortest-paths.md +++ b/site/content/3.12/aql/graphs/all-shortest-paths.md @@ -117,6 +117,56 @@ All collections in the list that do not specify their own direction use the direction defined after `IN` (here: `OUTBOUND`). This allows using a different direction for each collection in your path search. +### Graph path searches in a cluster + +Due to the nature of graphs, edges may reference nodes from arbitrary +collections. Following the paths can thus involve documents from various +collections and it is not possible to predict which are visited in a +traversal. Which collections need to be loaded by the graph engine can only be +determined at run time. + +Use the [`WITH` operation](../high-level-operations/with.md) to specify the +node collections you expect to be involved. This is required for traversals +using collection sets in cluster deployments. Declare the collection of the +start node as well if it's not declared already (like by a `FOR` loop). + +{{< tip >}} +From v3.12.6 onward, node collections are automatically deduced for graph +queries using collection sets / anonymous graphs if there is a named graph with +a matching edge collection in its edge definitions. + +For example, suppose you have two node collections, `person` and `movie`, and +an `acts_in` edge collection that connects them. If you want to run a path search +query that starts (and ends) at a person that you specify with its document ID, +you need to declare both node collections at the beginning of the query: + +```aql +WITH person, movie +FOR p IN ANY ALL_SHORTEST_PATHS "person/1544" TO "person/52560" acts_in + RETURN p.vertices[*].label +``` + +However, if there is a named graph that includes an edge definition for the +`acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection, you can omit `WITH person, movie`. That is, if you +specify `acts_in` as an edge collection in an anonymous graph query, all +named graphs are checked for this edge collection, and if there is a matching +edge definition, its node collections are automatically added as data sources to +the query. + +```aql +FOR p IN ANY ALL_SHORTEST_PATHS "person/1544" TO "person/52560" acts_in + RETURN p.vertices[*].label + +// Chris Rock --> Dogma <-- Ben Affleck --> Surviving Christmas <-- Jennifer Morrison +// Chris Rock --> The Longest Yard <-- Rob Schneider --> Big Stan <-- Jennifer Morrison +// Chris Rock --> Down to Earth <-- John Cho --> Star Trek <-- Jennifer Morrison +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. +{{< /tip >}} + ## Examples Load an example graph to get a named graph that reflects some possible diff --git a/site/content/3.12/aql/graphs/k-paths.md b/site/content/3.12/aql/graphs/k-paths.md index 89b63f6f41..c14e9158be 100644 --- a/site/content/3.12/aql/graphs/k-paths.md +++ b/site/content/3.12/aql/graphs/k-paths.md @@ -188,6 +188,57 @@ All collections in the list that do not specify their own direction use the direction defined after `IN` (here: `OUTBOUND`). This allows to use a different direction for each collection in your path search. +### Graph path searches in a cluster + +Due to the nature of graphs, edges may reference nodes from arbitrary +collections. Following the paths can thus involve documents from various +collections and it is not possible to predict which are visited in a +traversal. Which collections need to be loaded by the graph engine can only be +determined at run time. + +Use the [`WITH` operation](../high-level-operations/with.md) to specify the +node collections you expect to be involved. This is required for traversals +using collection sets in cluster deployments. Declare the collection of the +start node as well if it's not declared already (like by a `FOR` loop). + +{{< tip >}} +From v3.12.6 onward, node collections are automatically deduced for graph +queries using collection sets / anonymous graphs if there is a named graph with +a matching edge collection in its edge definitions. + +For example, suppose you have two node collections, `person` and `movie`, and +an `acts_in` edge collection that connects them. If you want to run a path search +query that starts (and ends) at a person that you specify with its document ID, +you need to declare both node collections at the beginning of the query: + +```aql +WITH person, movie +FOR p IN 4 ANY K_PATHS "person/1544" TO "person/52560" acts_in + LIMIT 2 + RETURN p.vertices[*].label +``` + +However, if there is a named graph that includes an edge definition for the +`acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection, you can omit `WITH person, movie`. That is, if you +specify `acts_in` as an edge collection in an anonymous graph query, all +named graphs are checked for this edge collection, and if there is a matching +edge definition, its node collections are automatically added as data sources to +the query. + +```aql +FOR p IN 4 ANY K_PATHS "person/1544" TO "person/52560" acts_in + LIMIT 2 + RETURN p.vertices[*].label + +// Chris Rock --> Dogma <-- Ben Affleck --> Surviving Christmas <-- Jennifer Morrison +// Chris Rock --> The Longest Yard <-- Rob Schneider --> Big Stan <-- Jennifer Morrison +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. +{{< /tip >}} + ## Examples You can load the `kShortestPathsGraph` example graph to get a named graph that diff --git a/site/content/3.12/aql/graphs/k-shortest-paths.md b/site/content/3.12/aql/graphs/k-shortest-paths.md index cad5ee1771..8b9c71c8aa 100644 --- a/site/content/3.12/aql/graphs/k-shortest-paths.md +++ b/site/content/3.12/aql/graphs/k-shortest-paths.md @@ -186,6 +186,57 @@ All collections in the list that do not specify their own direction use the direction defined after `IN` (here: `OUTBOUND`). This allows to use a different direction for each collection in your path search. +### Graph path searches in a cluster + +Due to the nature of graphs, edges may reference nodes from arbitrary +collections. Following the paths can thus involve documents from various +collections and it is not possible to predict which are visited in a +traversal. Which collections need to be loaded by the graph engine can only be +determined at run time. + +Use the [`WITH` operation](../high-level-operations/with.md) to specify the +node collections you expect to be involved. This is required for traversals +using collection sets in cluster deployments. Declare the collection of the +start node as well if it's not declared already (like by a `FOR` loop). + +{{< tip >}} +From v3.12.6 onward, node collections are automatically deduced for graph +queries using collection sets / anonymous graphs if there is a named graph with +a matching edge collection in its edge definitions. + +For example, suppose you have two node collections, `person` and `movie`, and +an `acts_in` edge collection that connects them. If you want to run a path search +query that starts (and ends) at a person that you specify with its document ID, +you need to declare both node collections at the beginning of the query: + +```aql +WITH person, movie +FOR p IN ANY K_SHORTEST_PATHS "person/1544" TO "person/52560" acts_in + LIMIT 2 + RETURN p.vertices[*].label +``` + +However, if there is a named graph that includes an edge definition for the +`acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection, you can omit `WITH person, movie`. That is, if you +specify `acts_in` as an edge collection in an anonymous graph query, all +named graphs are checked for this edge collection, and if there is a matching +edge definition, its node collections are automatically added as data sources to +the query. + +```aql +FOR p IN ANY K_SHORTEST_PATHS "person/1544" TO "person/52560" acts_in + LIMIT 2 + RETURN p.vertices[*].label + +// Chris Rock --> Dogma <-- Ben Affleck --> Surviving Christmas <-- Jennifer Morrison +// Chris Rock --> The Longest Yard <-- Rob Schneider --> Big Stan <-- Jennifer Morrison +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. +{{< /tip >}} + ## Examples You can load the `kShortestPathsGraph` example graph to get a named graph that diff --git a/site/content/3.12/aql/graphs/shortest-path.md b/site/content/3.12/aql/graphs/shortest-path.md index 7f0b6421fa..2427bcb2e5 100644 --- a/site/content/3.12/aql/graphs/shortest-path.md +++ b/site/content/3.12/aql/graphs/shortest-path.md @@ -145,6 +145,54 @@ All collections in the list that do not specify their own direction use the direction defined after `IN` (here: `OUTBOUND`). This allows you to use a different direction for each collection in your path search. +### Graph path searches in a cluster + +Due to the nature of graphs, edges may reference nodes from arbitrary +collections. Following the paths can thus involve documents from various +collections and it is not possible to predict which are visited in a +traversal. Which collections need to be loaded by the graph engine can only be +determined at run time. + +Use the [`WITH` operation](../high-level-operations/with.md) to specify the +node collections you expect to be involved. This is required for traversals +using collection sets in cluster deployments. Declare the collection of the +start node as well if it's not declared already (like by a `FOR` loop). + +{{< tip >}} +From v3.12.6 onward, node collections are automatically deduced for graph +queries using collection sets / anonymous graphs if there is a named graph with +a matching edge collection in its edge definitions. + +For example, suppose you have two node collections, `person` and `movie`, and +an `acts_in` edge collection that connects them. If you want to run a path search +query that starts (and ends) at a person that you specify with its document ID, +you need to declare both node collections at the beginning of the query: + +```aql +WITH person, movie +FOR v IN ANY SHORTEST_PATH "person/1544" TO "person/52560" acts_in + RETURN v.label +``` + +However, if there is a named graph that includes an edge definition for the +`acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection, you can omit `WITH person, movie`. That is, if you +specify `acts_in` as an edge collection in an anonymous graph query, all +named graphs are checked for this edge collection, and if there is a matching +edge definition, its node collections are automatically added as data sources to +the query. + +```aql +FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in + RETURN v.label + +// Chris Rock --> Dogma <-- Ben Affleck --> Surviving Christmas <-- Jennifer Morrison +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. +{{< /tip >}} + ## Conditional shortest path The `SHORTEST_PATH` computation only finds an unconditioned shortest path. diff --git a/site/content/3.12/aql/graphs/traversals.md b/site/content/3.12/aql/graphs/traversals.md index 2f9d5dc699..ea585dda82 100644 --- a/site/content/3.12/aql/graphs/traversals.md +++ b/site/content/3.12/aql/graphs/traversals.md @@ -342,14 +342,49 @@ collections and it is not possible to predict which are visited in a traversal. Which collections need to be loaded by the graph engine can only be determined at run time. -Use the [`WITH` statement](../high-level-operations/with.md) to specify the collections you -expect to be involved. This is required for traversals using collection sets -in cluster deployments. +Use the [`WITH` operation](../high-level-operations/with.md) to specify the +node collections you expect to be involved. This is required for traversals +using collection sets in cluster deployments. Declare the collection of the +start node as well if it's not declared already (like by a `FOR` loop). {{< tip >}} -From v3.12.6 onward, vertex collections are automatically deduced for graph +From v3.12.6 onward, node collections are automatically deduced for graph queries using collection sets / anonymous graphs if there is a named graph with a matching edge collection in its edge definitions. + +For example, suppose you have two node collections, `person` and `movie`, and +an `acts_in` edge collection that connects them. If you want to run a traversal +query that starts at a person that you specify with its document ID, +you need to declare both node collections at the beginning of the query: + +```aql +WITH person, movie +FOR v IN 1 OUTBOUND "person/1544" acts_in + LIMIT 3 + RETURN v.label +``` + +However, if there is a named graph that includes an edge definition for the +`acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection, you can omit `WITH person, movie`. That is, if you +specify `acts_in` as an edge collection in an anonymous graph query, all +named graphs are checked for this edge collection, and if there is a matching +edge definition, its node collections are automatically added as data sources to +the query. + +```aql +FOR v, IN 0..1 OUTBOUND "person/1544" acts_in + LIMIT 4 + RETURN v.label + +// Chris Rock +// A.I. Artificial Intelligence +// Lethal Weapon 4 +// Madagascar +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. {{< /tip >}} ## Pruning diff --git a/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md b/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md index ff9f44244e..95ea301964 100644 --- a/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md +++ b/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md @@ -1300,13 +1300,15 @@ Indexes used: AQL graph traversals and path searches using anonymous graphs / collection sets require that you declare all involved node collections upfront for cluster deployments. That is, you need to use the `WITH` operation to list the collections -edges may point to, as well as the start vertex collection if not declared +edges may point to, as well as the collection of the start node if not declared otherwise. This also applies to single servers if the `--query.require-with` startup option is enabled for parity between both deployment modes. -For example, the node collection of the start vertex is `person` and the edges -stored in the `acts_in` edge collection point to a `movie` node collection. -Both need to be declared at the beginning of the query: +For example, assume you have two node collections, `person` and `movie`, and +edges pointing from one to the other stored in an `acts_in` edge collection. +If you want to run a traversal query starting from a person that you specify +with its document ID, you need to declare both node collections at the +beginning of the query: ```aql WITH person, movie @@ -1314,10 +1316,8 @@ FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in RETURN v.label ``` -From v3.12.6 onward, the vertex collections can be automatically inferred if -there is a named graph using the same edge collection(s) or if you use -`OPTIONS { vertexCollections: ... }` in queries to restrict which -node collections a traversal may visit. +From v3.12.6 onward, the node collections can be automatically inferred if there +is a named graph using the same edge collection(s). For example, assume there is a named graph that includes an edge definition for the `acts_in` edge collection, with `person` as the _from_ collection and `movie` @@ -1332,8 +1332,8 @@ FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in RETURN v.label ``` -You can still declare collections manually, in which case they are also added -as data sources in addition to automatically deduced collections. +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. ## Indexing diff --git a/site/content/3.13/aql/graphs/all-shortest-paths.md b/site/content/3.13/aql/graphs/all-shortest-paths.md index 69c770af05..248c7b2cae 100644 --- a/site/content/3.13/aql/graphs/all-shortest-paths.md +++ b/site/content/3.13/aql/graphs/all-shortest-paths.md @@ -117,6 +117,58 @@ All collections in the list that do not specify their own direction use the direction defined after `IN` (here: `OUTBOUND`). This allows using a different direction for each collection in your path search. +### Graph path searches in a cluster + +Due to the nature of graphs, edges may reference nodes from arbitrary +collections. Following the paths can thus involve documents from various +collections and it is not possible to predict which are visited in a path +search - unless you use named graphs that define all node and edge collections +that belong to them and the graph data is consistent. + +If you use anonymous graphs / collection sets for graph queries, which node +collections need to be loaded by the graph engine can deduced automatically if +there is a named graph with a matching edge collection in its edge definitions +(introduced in v3.12.6). Edge collections are always declared explicitly in +queries, directly or via referencing a named graph. + +Without a named graph, the involved node collections can only be determined at +run time. Use the [`WITH` operation](../high-level-operations/with.md) to +declare the node collections upfront. This is required for path searches +using collection sets in cluster deployments (if there is no named graph to +deduce the node collections from). Declare the collection of the start node as +well if it's not declared already (like by a `FOR` loop). + +For example, suppose you have two node collections, `person` and `movie`, and +an `acts_in` edge collection that connects them. If you want to run a path search +query that starts (and ends) at a person that you specify with its document ID, +you need to declare both node collections at the beginning of the query: + +```aql +WITH person, movie +FOR p IN ANY ALL_SHORTEST_PATHS "person/1544" TO "person/52560" acts_in + RETURN p.vertices[*].label +``` + +However, if there is a named graph that includes an edge definition for the +`acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection, you can omit `WITH person, movie`. That is, if you +specify `acts_in` as an edge collection in an anonymous graph query, all +named graphs are checked for this edge collection, and if there is a matching +edge definition, its node collections are automatically added as data sources to +the query. + +```aql +FOR p IN ANY ALL_SHORTEST_PATHS "person/1544" TO "person/52560" acts_in + RETURN p.vertices[*].label + +// Chris Rock --> Dogma <-- Ben Affleck --> Surviving Christmas <-- Jennifer Morrison +// Chris Rock --> The Longest Yard <-- Rob Schneider --> Big Stan <-- Jennifer Morrison +// Chris Rock --> Down to Earth <-- John Cho --> Star Trek <-- Jennifer Morrison +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. + ## Examples Load an example graph to get a named graph that reflects some possible diff --git a/site/content/3.13/aql/graphs/k-paths.md b/site/content/3.13/aql/graphs/k-paths.md index 89b63f6f41..9161ac76f8 100644 --- a/site/content/3.13/aql/graphs/k-paths.md +++ b/site/content/3.13/aql/graphs/k-paths.md @@ -188,6 +188,59 @@ All collections in the list that do not specify their own direction use the direction defined after `IN` (here: `OUTBOUND`). This allows to use a different direction for each collection in your path search. +### Graph path searches in a cluster + +Due to the nature of graphs, edges may reference nodes from arbitrary +collections. Following the paths can thus involve documents from various +collections and it is not possible to predict which are visited in a path +search - unless you use named graphs that define all node and edge collections +that belong to them and the graph data is consistent. + +If you use anonymous graphs / collection sets for graph queries, which node +collections need to be loaded by the graph engine can deduced automatically if +there is a named graph with a matching edge collection in its edge definitions +(introduced in v3.12.6). Edge collections are always declared explicitly in +queries, directly or via referencing a named graph. + +Without a named graph, the involved node collections can only be determined at +run time. Use the [`WITH` operation](../high-level-operations/with.md) to +declare the node collections upfront. This is required for path searches +using collection sets in cluster deployments (if there is no named graph to +deduce the node collections from). Declare the collection of the start node as +well if it's not declared already (like by a `FOR` loop). + +For example, suppose you have two node collections, `person` and `movie`, and +an `acts_in` edge collection that connects them. If you want to run a path search +query that starts (and ends) at a person that you specify with its document ID, +you need to declare both node collections at the beginning of the query: + +```aql +WITH person, movie +FOR p IN 4 ANY K_PATHS "person/1544" TO "person/52560" acts_in + LIMIT 2 + RETURN p.vertices[*].label +``` + +However, if there is a named graph that includes an edge definition for the +`acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection, you can omit `WITH person, movie`. That is, if you +specify `acts_in` as an edge collection in an anonymous graph query, all +named graphs are checked for this edge collection, and if there is a matching +edge definition, its node collections are automatically added as data sources to +the query. + +```aql +FOR p IN 4 ANY K_PATHS "person/1544" TO "person/52560" acts_in + LIMIT 2 + RETURN p.vertices[*].label + +// Chris Rock --> Dogma <-- Ben Affleck --> Surviving Christmas <-- Jennifer Morrison +// Chris Rock --> The Longest Yard <-- Rob Schneider --> Big Stan <-- Jennifer Morrison +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. + ## Examples You can load the `kShortestPathsGraph` example graph to get a named graph that diff --git a/site/content/3.13/aql/graphs/k-shortest-paths.md b/site/content/3.13/aql/graphs/k-shortest-paths.md index cad5ee1771..5bb4cf7e1e 100644 --- a/site/content/3.13/aql/graphs/k-shortest-paths.md +++ b/site/content/3.13/aql/graphs/k-shortest-paths.md @@ -186,6 +186,59 @@ All collections in the list that do not specify their own direction use the direction defined after `IN` (here: `OUTBOUND`). This allows to use a different direction for each collection in your path search. +### Graph path searches in a cluster + +Due to the nature of graphs, edges may reference nodes from arbitrary +collections. Following the paths can thus involve documents from various +collections and it is not possible to predict which are visited in a path +search - unless you use named graphs that define all node and edge collections +that belong to them and the graph data is consistent. + +If you use anonymous graphs / collection sets for graph queries, which node +collections need to be loaded by the graph engine can deduced automatically if +there is a named graph with a matching edge collection in its edge definitions +(introduced in v3.12.6). Edge collections are always declared explicitly in +queries, directly or via referencing a named graph. + +Without a named graph, the involved node collections can only be determined at +run time. Use the [`WITH` operation](../high-level-operations/with.md) to +declare the node collections upfront. This is required for path searches +using collection sets in cluster deployments (if there is no named graph to +deduce the node collections from). Declare the collection of the start node as +well if it's not declared already (like by a `FOR` loop). + +For example, suppose you have two node collections, `person` and `movie`, and +an `acts_in` edge collection that connects them. If you want to run a path search +query that starts (and ends) at a person that you specify with its document ID, +you need to declare both node collections at the beginning of the query: + +```aql +WITH person, movie +FOR p IN ANY K_SHORTEST_PATHS "person/1544" TO "person/52560" acts_in + LIMIT 2 + RETURN p.vertices[*].label +``` + +However, if there is a named graph that includes an edge definition for the +`acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection, you can omit `WITH person, movie`. That is, if you +specify `acts_in` as an edge collection in an anonymous graph query, all +named graphs are checked for this edge collection, and if there is a matching +edge definition, its node collections are automatically added as data sources to +the query. + +```aql +FOR p IN ANY K_SHORTEST_PATHS "person/1544" TO "person/52560" acts_in + LIMIT 2 + RETURN p.vertices[*].label + +// Chris Rock --> Dogma <-- Ben Affleck --> Surviving Christmas <-- Jennifer Morrison +// Chris Rock --> The Longest Yard <-- Rob Schneider --> Big Stan <-- Jennifer Morrison +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. + ## Examples You can load the `kShortestPathsGraph` example graph to get a named graph that diff --git a/site/content/3.13/aql/graphs/shortest-path.md b/site/content/3.13/aql/graphs/shortest-path.md index 7f0b6421fa..ac52c8ab71 100644 --- a/site/content/3.13/aql/graphs/shortest-path.md +++ b/site/content/3.13/aql/graphs/shortest-path.md @@ -145,6 +145,56 @@ All collections in the list that do not specify their own direction use the direction defined after `IN` (here: `OUTBOUND`). This allows you to use a different direction for each collection in your path search. +### Graph path searches in a cluster + +Due to the nature of graphs, edges may reference nodes from arbitrary +collections. Following the paths can thus involve documents from various +collections and it is not possible to predict which are visited in a path +search - unless you use named graphs that define all node and edge collections +that belong to them and the graph data is consistent. + +If you use anonymous graphs / collection sets for graph queries, which node +collections need to be loaded by the graph engine can deduced automatically if +there is a named graph with a matching edge collection in its edge definitions +(introduced in v3.12.6). Edge collections are always declared explicitly in +queries, directly or via referencing a named graph. + +Without a named graph, the involved node collections can only be determined at +run time. Use the [`WITH` operation](../high-level-operations/with.md) to +declare the node collections upfront. This is required for path searches +using collection sets in cluster deployments (if there is no named graph to +deduce the node collections from). Declare the collection of the start node as +well if it's not declared already (like by a `FOR` loop). + +For example, suppose you have two node collections, `person` and `movie`, and +an `acts_in` edge collection that connects them. If you want to run a path search +query that starts (and ends) at a person that you specify with its document ID, +you need to declare both node collections at the beginning of the query: + +```aql +WITH person, movie +FOR v IN ANY SHORTEST_PATH "person/1544" TO "person/52560" acts_in + RETURN v.label +``` + +However, if there is a named graph that includes an edge definition for the +`acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection, you can omit `WITH person, movie`. That is, if you +specify `acts_in` as an edge collection in an anonymous graph query, all +named graphs are checked for this edge collection, and if there is a matching +edge definition, its node collections are automatically added as data sources to +the query. + +```aql +FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in + RETURN v.label + +// Chris Rock --> Dogma <-- Ben Affleck --> Surviving Christmas <-- Jennifer Morrison +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. + ## Conditional shortest path The `SHORTEST_PATH` computation only finds an unconditioned shortest path. diff --git a/site/content/3.13/aql/graphs/traversals.md b/site/content/3.13/aql/graphs/traversals.md index d6ae7e2eeb..6bdc6b246d 100644 --- a/site/content/3.13/aql/graphs/traversals.md +++ b/site/content/3.13/aql/graphs/traversals.md @@ -338,13 +338,56 @@ collection in your traversal. Due to the nature of graphs, edges may reference nodes from arbitrary collections. Following the paths can thus involve documents from various -collections and it is not possible to predict which are visited in a -traversal. Which collections need to be loaded by the graph engine can only be -determined at run time. +collections and it is not possible to predict which are visited in a path +search - unless you use named graphs that define all node and edge collections +that belong to them and the graph data is consistent. -Use the [`WITH` statement](../high-level-operations/with.md) to specify the collections you -expect to be involved. This is required for traversals using collection sets -in cluster deployments. +If you use anonymous graphs / collection sets for graph queries, which node +collections need to be loaded by the graph engine can deduced automatically if +there is a named graph with a matching edge collection in its edge definitions +(introduced in v3.12.6). Edge collections are always declared explicitly in +queries, directly or via referencing a named graph. + +Without a named graph, the involved node collections can only be determined at +run time. Use the [`WITH` operation](../high-level-operations/with.md) to +declare the node collections upfront. This is required for traversals +using collection sets in cluster deployments (if there is no named graph to +deduce the node collections from). Declare the collection of the start node as +well if it's not declared already (like by a `FOR` loop). + +For example, suppose you have two node collections, `person` and `movie`, and +an `acts_in` edge collection that connects them. If you want to run a traversal +query that starts at a person that you specify with its document ID, +you need to declare both node collections at the beginning of the query: + +```aql +WITH person, movie +FOR v IN 1 OUTBOUND "person/1544" acts_in + LIMIT 3 + RETURN v.label +``` + +However, if there is a named graph that includes an edge definition for the +`acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection, you can omit `WITH person, movie`. That is, if you +specify `acts_in` as an edge collection in an anonymous graph query, all +named graphs are checked for this edge collection, and if there is a matching +edge definition, its node collections are automatically added as data sources to +the query. + +```aql +FOR v, IN 0..1 OUTBOUND "person/1544" acts_in + LIMIT 4 + RETURN v.label + +// Chris Rock +// A.I. Artificial Intelligence +// Lethal Weapon 4 +// Madagascar +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. ## Pruning diff --git a/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md b/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md index 9dc4aee978..95ea301964 100644 --- a/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md +++ b/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md @@ -1293,6 +1293,48 @@ Indexes used: 10 idx_1836452431376941056 persistent coll ``` +### Deduction of node collection for graph queries + +Introduced in: v3.12.6 + +AQL graph traversals and path searches using anonymous graphs / collection sets +require that you declare all involved node collections upfront for cluster +deployments. That is, you need to use the `WITH` operation to list the collections +edges may point to, as well as the collection of the start node if not declared +otherwise. This also applies to single servers if the `--query.require-with` +startup option is enabled for parity between both deployment modes. + +For example, assume you have two node collections, `person` and `movie`, and +edges pointing from one to the other stored in an `acts_in` edge collection. +If you want to run a traversal query starting from a person that you specify +with its document ID, you need to declare both node collections at the +beginning of the query: + +```aql +WITH person, movie +FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in + RETURN v.label +``` + +From v3.12.6 onward, the node collections can be automatically inferred if there +is a named graph using the same edge collection(s). + +For example, assume there is a named graph that includes an edge definition for +the `acts_in` edge collection, with `person` as the _from_ collection and `movie` +as the _to_ collection. If you now specify `acts_in` as an edge collection in +an anonymous graph query, all named graphs are checked for this edge collection, +and if there is a matching edge definition, its node collections are automatically +added as data sources to the query. You no longer have to manually declare the +`person` and `movie` collections: + +```aql +FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in + RETURN v.label +``` + +You can still declare collections manually, in which case they are added as +data sources in addition to automatically deduced collections. + ## Indexing ### Multi-dimensional indexes From eec21f1b4d225ced9fac2e7ebacc2554d8aedd1b Mon Sep 17 00:00:00 2001 From: Simran Spiller Date: Wed, 15 Oct 2025 14:30:11 +0200 Subject: [PATCH 4/5] Modify release notes example --- .../3.12/release-notes/version-3.12/whats-new-in-3-12.md | 6 ++++-- .../3.13/release-notes/version-3.12/whats-new-in-3-12.md | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md b/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md index 95ea301964..e9097d6c98 100644 --- a/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md +++ b/site/content/3.12/release-notes/version-3.12/whats-new-in-3-12.md @@ -1312,7 +1312,8 @@ beginning of the query: ```aql WITH person, movie -FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in +FOR v IN 0..1 OUTBOUND "person/1544" acts_in + LIMIT 4 RETURN v.label ``` @@ -1328,7 +1329,8 @@ added as data sources to the query. You no longer have to manually declare the `person` and `movie` collections: ```aql -FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in +FOR v IN 0..1 OUTBOUND "person/1544" acts_in + LIMIT 4 RETURN v.label ``` diff --git a/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md b/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md index 95ea301964..e9097d6c98 100644 --- a/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md +++ b/site/content/3.13/release-notes/version-3.12/whats-new-in-3-12.md @@ -1312,7 +1312,8 @@ beginning of the query: ```aql WITH person, movie -FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in +FOR v IN 0..1 OUTBOUND "person/1544" acts_in + LIMIT 4 RETURN v.label ``` @@ -1328,7 +1329,8 @@ added as data sources to the query. You no longer have to manually declare the `person` and `movie` collections: ```aql -FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in +FOR v IN 0..1 OUTBOUND "person/1544" acts_in + LIMIT 4 RETURN v.label ``` From 0766a84d273b2c4dab416889a25715c732413fc8 Mon Sep 17 00:00:00 2001 From: Simran Spiller Date: Tue, 21 Oct 2025 23:28:26 +0200 Subject: [PATCH 5/5] Fix/unify examples --- site/content/3.12/aql/graphs/shortest-path.md | 2 +- site/content/3.12/aql/graphs/traversals.md | 4 ++-- site/content/3.13/aql/graphs/shortest-path.md | 2 +- site/content/3.13/aql/graphs/traversals.md | 4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/site/content/3.12/aql/graphs/shortest-path.md b/site/content/3.12/aql/graphs/shortest-path.md index 2427bcb2e5..29f1db66df 100644 --- a/site/content/3.12/aql/graphs/shortest-path.md +++ b/site/content/3.12/aql/graphs/shortest-path.md @@ -183,7 +183,7 @@ edge definition, its node collections are automatically added as data sources to the query. ```aql -FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in +FOR v IN ANY SHORTEST_PATH "person/1544" TO "person/52560" acts_in RETURN v.label // Chris Rock --> Dogma <-- Ben Affleck --> Surviving Christmas <-- Jennifer Morrison diff --git a/site/content/3.12/aql/graphs/traversals.md b/site/content/3.12/aql/graphs/traversals.md index ea585dda82..c30c4c8820 100644 --- a/site/content/3.12/aql/graphs/traversals.md +++ b/site/content/3.12/aql/graphs/traversals.md @@ -359,8 +359,8 @@ you need to declare both node collections at the beginning of the query: ```aql WITH person, movie -FOR v IN 1 OUTBOUND "person/1544" acts_in - LIMIT 3 +FOR v, IN 0..1 OUTBOUND "person/1544" acts_in + LIMIT 4 RETURN v.label ``` diff --git a/site/content/3.13/aql/graphs/shortest-path.md b/site/content/3.13/aql/graphs/shortest-path.md index ac52c8ab71..06ea980edd 100644 --- a/site/content/3.13/aql/graphs/shortest-path.md +++ b/site/content/3.13/aql/graphs/shortest-path.md @@ -186,7 +186,7 @@ edge definition, its node collections are automatically added as data sources to the query. ```aql -FOR v,e,p IN 1..1 OUTBOUND "person/1544" acts_in +FOR v IN ANY SHORTEST_PATH "person/1544" TO "person/52560" acts_in RETURN v.label // Chris Rock --> Dogma <-- Ben Affleck --> Surviving Christmas <-- Jennifer Morrison diff --git a/site/content/3.13/aql/graphs/traversals.md b/site/content/3.13/aql/graphs/traversals.md index 6bdc6b246d..b60206583e 100644 --- a/site/content/3.13/aql/graphs/traversals.md +++ b/site/content/3.13/aql/graphs/traversals.md @@ -362,8 +362,8 @@ you need to declare both node collections at the beginning of the query: ```aql WITH person, movie -FOR v IN 1 OUTBOUND "person/1544" acts_in - LIMIT 3 +FOR v, IN 0..1 OUTBOUND "person/1544" acts_in + LIMIT 4 RETURN v.label ```