remove apendix and reorganize procedures

renetapopova · renetapopova · commit 338db0ad89b7 · 2024-10-15T10:11:41.000+01:00
diff --git a/modules/ROOT/content-nav.adoc b/modules/ROOT/content-nav.adoc
@@ -125,6 +125,7 @@
 *** xref:database-administration/composite-databases/querying-composite-databases.adoc[]
 *** xref:database-administration/composite-databases/sharding-with-copy.adoc[]
 ** xref:database-administration/syntax.adoc[]
+** xref:database-administration/routing-decisions.adoc[]
 
 * xref:database-internals/index.adoc[]
 ** xref:database-internals/transaction-management.adoc[]
@@ -236,6 +237,8 @@
 *** xref:tools/neo4j-admin/validate-config.adoc[]
 ** xref:tools/cypher-shell.adoc[]
 
+* xref:procedures.adoc[]
+
 * xref:tutorial/index.adoc[]
 //** xref:tutorial/local-causal-cluster.adoc[]
 //** xref:tutorial/causal-backup-restore-db.adoc[]
@@ -246,10 +249,6 @@
 ** xref:tutorial/tutorial-immutable-privileges.adoc[]
 ** xref:tutorial/tutorial-clustering-docker.adoc[]
 
-* Appendix
-** xref:reference/procedures.adoc[]
-** xref:routing-decisions.adoc[]
-
 // ** xref:clustering-advanced/index.adoc[]
 // *** xref:clustering-advanced/lifecycle.adoc[]
 // *** xref:clustering-advanced/multi-data-center/index.adoc[]
diff --git a/modules/ROOT/pages/authentication-authorization/ldap-integration.adoc b/modules/ROOT/pages/authentication-authorization/ldap-integration.adoc
@@ -65,7 +65,7 @@ this LDAP group will fail authentication, even if their credentials are correct.
 |===
 
 All settings are defined at server startup time in the default configuration file _xref:configuration/neo4j-conf.adoc[neo4j.conf]_ or can be modified at
-runtime using xref:reference/procedures.adoc#procedure_dbms_setconfigvalue[`dbms.setConfigValue()`].
+runtime using xref:procedures.adoc#procedure_dbms_setconfigvalue[`dbms.setConfigValue()`].
 
 
 [[auth-ldap-configure-provider]]
diff --git a/modules/ROOT/pages/clustering/databases.adoc b/modules/ROOT/pages/clustering/databases.adoc
@@ -111,9 +111,9 @@ By default, a newly created database has both read and write access.
 
 To relieve the load of a specific server(s), you can use one of the following procedures to deallocate databases causing the pressure from the server(s):
 
-* xref:reference/procedures.adoc#procedure_dbms_cluster_deallocateDatabaseFromServer[`dbms.cluster.deallocateDatabaseFromServer("server-name", "database-name")`]
-* xref:reference/procedures.adoc#procedure_dbms_cluster_deallocateDatabaseFromServers[`dbms.cluster.deallocateDatabaseFromServers(["server-name1", "server-name2"\], "database-name")`]
-* xref:reference/procedures.adoc#procedure_dbms_cluster_deallocateNumberOfDatabases[`dbms.cluster.deallocateNumberOfDatabases("server-name", number)`]
+* xref:procedures.adoc#procedure_dbms_cluster_deallocateDatabaseFromServer[`dbms.cluster.deallocateDatabaseFromServer("server-name", "database-name")`]
+* xref:procedures.adoc#procedure_dbms_cluster_deallocateDatabaseFromServers[`dbms.cluster.deallocateDatabaseFromServers(["server-name1", "server-name2"\], "database-name")`]
+* xref:procedures.adoc#procedure_dbms_cluster_deallocateNumberOfDatabases[`dbms.cluster.deallocateNumberOfDatabases("server-name", number)`]
 
 [NOTE]
 ====
@@ -166,7 +166,7 @@ To rebalance all database allocations across the cluster, for example, because y
 [[reallocate-databases-procedure]]
 === Reallocate databases using a procedure
 
-You can use the procedure xref:reference/procedures.adoc#procedure_dbms_cluster_reallocateDatabase[`dbms.cluster.reallocateDatabase`] to rebalance a specific database across the cluster, or xref:reference/procedures.adoc#procedure_dbms_cluster_reallocateNumberOfDatabases[`dbms.cluster.reallocateNumberOfDatabases`] to rebalance a number of database allocations across the cluster and relieve overloaded servers.
+You can use the procedure xref:procedures.adoc#procedure_dbms_cluster_reallocateDatabase[`dbms.cluster.reallocateDatabase`] to rebalance a specific database across the cluster, or xref:procedures.adoc#procedure_dbms_cluster_reallocateNumberOfDatabases[`dbms.cluster.reallocateNumberOfDatabases`] to rebalance a number of database allocations across the cluster and relieve overloaded servers.
 Note that if the cluster is already balanced, no reallocations will happen when running these procedures.
 These procedures do not require a server name and can be executed with or without a dry run.
 
@@ -206,7 +206,7 @@ This command can also be used with `DRYRUN` to preview the new allocation of dat
 [CAUTION]
 ====
 `REALLOCATE DATABASES` on a large cluster with many databases has the potential to move a lot of allocations at once, which might stress the cluster.
-Consider starting with more limited reallocations, such as xref:reference/procedures.adoc#procedure_dbms_cluster_reallocateNumberOfDatabases[`dbms.cluster.reallocateNumberOfDatabases`] with a small number, and let the databases complete their reallocation before calling it again, until no more reallocations are necessary.
+Consider starting with more limited reallocations, such as xref:procedures.adoc#procedure_dbms_cluster_reallocateNumberOfDatabases[`dbms.cluster.reallocateNumberOfDatabases`] with a small number, and let the databases complete their reallocation before calling it again, until no more reallocations are necessary.
 ====
 
 [NOTE]
@@ -557,7 +557,7 @@ If not set, there are no mode constraints on the server.
 [[cluster-default-database]]
 == Change the default database
 
-You can use the procedure xref:reference/procedures.adoc#procedure_dbms_setDefaultDatabase[`dbms.setDefaultDatabase("newDefaultDatabaseName")`] to change the default database for a DBMS.
+You can use the procedure xref:procedures.adoc#procedure_dbms_setDefaultDatabase[`dbms.setDefaultDatabase("newDefaultDatabaseName")`] to change the default database for a DBMS.
 
 . Ensure that the database to be set as default exists, otherwise create it using the command `CREATE DATABASE <database-name>`.
 . Show the name and status of the current default database by using the command `SHOW DEFAULT DATABASE`.
diff --git a/modules/ROOT/pages/clustering/servers.adoc b/modules/ROOT/pages/clustering/servers.adoc
@@ -96,7 +96,7 @@ Note that there is a known situation in which a previously deallocated offline s
 
 The _Cordoned_ state is similar to _Deallocating_ in that servers in this state will not be allocated to host additional databases.
 Unlike _Deallocating_ however, cordoned servers do not lose the databases they already host.
-It is worth noting that when decreasing the number of allocations of a database, allocations on cordoned servers are removed first. 
+It is worth noting that when decreasing the number of allocations of a database, allocations on cordoned servers are removed first.
 
 A server is transitioned from the _Enabled_ state to the _Cordoned_ state by executing the procedure `dbms.cluster.cordonServer`.
 A server in the _Cordoned_ state may be transitioned to _Deallocating_, or back to _Enabled_.
@@ -276,7 +276,7 @@ neo4j@neo4j> ENABLE SERVER '25a7efc7-d063-44b8-bdee-f23357f89f01' OPTIONS
 The `allowedDatabases` and `deniedDatabases` are mutually exclusive and if both are specified, an error is returned.
 
 Optionally, it is possible to automatically enable free servers by setting the xref:configuration/configuration-settings.adoc#config_initial.dbms.automatically_enable_free_servers[`initial.dbms.automatically_enable_free_servers`] to `true`.
-This can be changed after startup using the xref:reference/procedures.adoc#procedure_dbms_cluster_setAutomaticallyEnableFreeServers[`dbms.cluster.setAutomaticallyEnableFreeServers`] procedure.
+This can be changed after startup using the xref:procedures.adoc#procedure_dbms_cluster_setAutomaticallyEnableFreeServers[`dbms.cluster.setAutomaticallyEnableFreeServers`] procedure.
 
 Server `tags` are used during database allocation and when configuring load balancing and replication policies.
 They cannot contain duplicates, so `tags:['eu', 'eu']` will return an error.
diff --git a/modules/ROOT/pages/clustering/settings.adoc b/modules/ROOT/pages/clustering/settings.adoc
@@ -20,7 +20,7 @@ This server always only hosts those databases in `SECONDARY` mode.
 
 | xref:configuration/configuration-settings.adoc#config_initial.dbms.automatically_enable_free_servers[`initial.dbms.automatically_enable_free_servers`]
 | This setting allows for auto-enable of servers in the `FREE` state.
-After startup, it can be changed with the xref:reference/procedures.adoc#procedure_dbms_cluster_setAutomaticallyEnableFreeServers[`dbms.cluster.setAutomaticallyEnableFreeServers`] procedure.
+After startup, it can be changed with the xref:procedures.adoc#procedure_dbms_cluster_setAutomaticallyEnableFreeServers[`dbms.cluster.setAutomaticallyEnableFreeServers`] procedure.
 
 | xref:configuration/configuration-settings.adoc#config_server.cluster.system_database_mode[`server.cluster.system_database_mode`]
 | Every cluster member hosts the `system` database.
diff --git a/modules/ROOT/pages/clustering/setup/deploy.adoc b/modules/ROOT/pages/clustering/setup/deploy.adoc
@@ -46,9 +46,9 @@ If not specified, it defaults to zero hostings in secondary mode.
 [NOTE]
 ====
 Any setting with the `initial` prefix is only effective on the first startup of the DBMS.
-Changing the default number of primaries and secondaries dynamically can only be done with the xref:reference/procedures.adoc#procedure_dbms_setDefaultAllocationNumbers[`dbms.setDefaultAllocationNumbers`] procedure.
+Changing the default number of primaries and secondaries dynamically can only be done with the xref:procedures.adoc#procedure_dbms_setDefaultAllocationNumbers[`dbms.setDefaultAllocationNumbers`] procedure.
 See xref:clustering/databases.adoc#_create_database[`CREATE DATABASE`] for more information.
-To view the current default settings, use the xref:reference/procedures.adoc#procedure_dbms_showTopologyGraphConfig[`dbms.showTopologyGraphConfig`] procedure.
+To view the current default settings, use the xref:procedures.adoc#procedure_dbms_showTopologyGraphConfig[`dbms.showTopologyGraphConfig`] procedure.
 ====
 
 
diff --git a/modules/ROOT/pages/database-administration/routing-decisions.adoc b/modules/ROOT/pages/database-administration/routing-decisions.adoc
@@ -1,13 +1,11 @@
-[appendix]
 [role=enterprise-edition]
-[[appendix-routing-decisions]]
+[[routing-decisions]]
 = Query routing decisions
 :description: This page describes in detail how queries are routed to databases for execution.
 
 Query routing is the process of deciding which Cypher executor (database) should be used and at which physical location the query should be executed.
 Every query that arrives at a Neo4j server, over the bolt protocol from a driver, undergoes the process described here.
 
-[[appendix-routing-decisions-tree]]
 == Routing decision tree
 
 Before the query is executed, these are the decisions taken during query routing stage:
@@ -52,6 +50,5 @@ Step 5: Open a transaction::
 Step 6: Execute query::
 * Execute the query in the open transaction.
 
-[[appendix-routing-decisions-tree-illustrated]]
 == Illustrated routing decision tree
 image::routing-decisions.svg[width=800, title="Illustrated routing decision tree"]
diff --git a/modules/ROOT/pages/database-administration/standard-databases/errors.adoc b/modules/ROOT/pages/database-administration/standard-databases/errors.adoc
@@ -162,7 +162,7 @@ It produces a database dump that can be further examined and potentially repaire
 
 There are two ways to get a database into a `quarantined` state:
 
-* By using the xref:reference/procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase`] procedure locally to isolate a specific database.
+* By using the xref:procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase`] procedure locally to isolate a specific database.
 The procedure must be executed on the instance whose copy of the database you want to quarantine.
 A reason for that can be, for example, when a database is unable to start on a given instance due to a file system permissions issue with the volume where the database is located or when a recently started database begins to log errors.
 The quarantine state renders the database inaccessible on that instance and prevents its state from being changed, for example, with the `START DATABASE` command.
@@ -210,7 +210,7 @@ The result contains the user, the time, and the reason for the quarantine.
 
 [NOTE]
 ====
-The `dbms.quarantineDatabase` procedure replaces xref:reference/procedures.adoc#procedure_dbms_cluster_quarantinedatabase[`dbms.cluster.quarantineDatabase`], which has been deprecated in Neo4j 4.3 and will be removed with the next major version.
+The `dbms.quarantineDatabase` procedure replaces xref:procedures.adoc#procedure_dbms_cluster_quarantinedatabase[`dbms.cluster.quarantineDatabase`], which has been deprecated in Neo4j 4.3 and will be removed with the next major version.
 ====
 
 .Quarantine a database
@@ -251,7 +251,7 @@ neo4j@system> SHOW DATABASE foo;
 ====
 A `quarantined` state is persisted for user databases.
 This means that if a database is quarantined, it will remain so even if that Neo4j instance is restarted.
-You can remove it only by running the xref:reference/procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase`] procedure on the instance where the quarantined database is located, passing `false` for the `setStatus` parameter.
+You can remove it only by running the xref:procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase`] procedure on the instance where the quarantined database is located, passing `false` for the `setStatus` parameter.
 
 The one exception to this rule is for the built-in `system` database.
 Any quarantine for that database is removed automatically after instance restart.
diff --git a/modules/ROOT/pages/database-internals/transaction-logs.adoc b/modules/ROOT/pages/database-internals/transaction-logs.adoc
@@ -85,7 +85,7 @@ Old transaction logs cannot be safely archived or removed by external jobs since
 Log pruning is called only after checkpoint completion to ensure at least one checkpoint and points to a valid place in the transaction log data.
 In reality, this means that all transaction logs created between checkpoints are kept for some time, and only after a checkpoint, the pruning strategy removes them.
 For more details on how to speed up checkpointing, see xref:database-internals/checkpointing.adoc#transaction-logging-log-pruning[Configure log pruning].
-To force a checkpoint, run the procedure xref:reference/procedures.adoc#procedure_db_checkpoint[`CALL db.checkpoint()`].
+To force a checkpoint, run the procedure xref:procedures.adoc#procedure_db_checkpoint[`CALL db.checkpoint()`].
 +
 [NOTE]
 ====
diff --git a/modules/ROOT/pages/monitoring/logging.adoc b/modules/ROOT/pages/monitoring/logging.adoc
@@ -1006,7 +1006,7 @@ The last two parenthesis `{}` `{}` are for the query parameters and `txMetaData`
 [[attach-metadata-tx]]
 === Attach metadata to a transaction
 
-You can attach metadata to a transaction and have it printed in the query log using the built-in procedure xref:reference/procedures.adoc#procedure_tx_setmetadata[`tx.setMetaData`].
+You can attach metadata to a transaction and have it printed in the query log using the built-in procedure xref:procedures.adoc#procedure_tx_setmetadata[`tx.setMetaData`].
 
 [NOTE]
 ====
@@ -1032,7 +1032,7 @@ Every graph app should follow a convention for passing metadata with the queries
 
 This is typically done programmatically but can also be used with the Neo4j dev tools. +
 In general, you start a transaction on a user database and attach a list of metadata to it by calling `tx.setMetaData`.
-You can also use the procedure xref:reference/procedures.adoc#procedure_tx_getmetadata[`CALL tx.getMetaData()`] to show the metadata of the current transaction.
+You can also use the procedure xref:procedures.adoc#procedure_tx_getmetadata[`CALL tx.getMetaData()`] to show the metadata of the current transaction.
 These examples use the MovieGraph dataset from the link:https://neo4j.com/docs/browser-manual/current/visual-tour/#guides[Neo4j Browser guide].
 
 .Using `cypher-shell`, attach metadata to a transaction
diff --git a/modules/ROOT/pages/performance/space-reuse.adoc b/modules/ROOT/pages/performance/space-reuse.adoc
@@ -106,7 +106,7 @@ neo4j@neo4j> MATCH (n:testnode1) RETURN ID(n) as ID order by ID limit 5;
 5 rows available after 171 ms, consumed after another 84 ms
 ----
 +
-. Run xref:reference/procedures.adoc#procedure_db_checkpoint[`call db.checkpoint()`] procedure to force a checkpoint.
+. Run xref:procedures.adoc#procedure_db_checkpoint[`call db.checkpoint()`] procedure to force a checkpoint.
 +
 [source, shell]
 ----
diff --git a/modules/ROOT/pages/performance/statistics-execution-plans.adoc b/modules/ROOT/pages/performance/statistics-execution-plans.adoc
@@ -57,15 +57,15 @@ You can control whether and how often statistics are collected automatically by
 
 You can manually trigger index resampling by using the built-in procedures `db.resampleIndex()` and `db.resampleOutdatedIndexes()`.
 
-xref:reference/procedures.adoc#procedure_db_resampleindex[`db.resampleIndex()`]::
+xref:procedures.adoc#procedure_db_resampleindex[`db.resampleIndex()`]::
 Trigger resampling of a specified index.
 +
 [source, cypher]
 ----
 CALL db.resampleIndex("indexName")
 ----
 
-xref:reference/procedures.adoc#procedure_db_resampleoutdatedindexes[`db.resampleOutdatedIndexes()`]::
+xref:procedures.adoc#procedure_db_resampleoutdatedindexes[`db.resampleOutdatedIndexes()`]::
 Trigger resampling of all outdated indexes.
 +
 [source, cypher]
@@ -108,7 +108,7 @@ This ensures that even moderately changing databases see query replanning after
 
 You can manually force the database to replan the execution plans that are already in the cache by using the following built-in procedures:
 
-xref:reference/procedures.adoc#procedure_db_clearquerycaches[`db.clearQueryCaches()`]::
+xref:procedures.adoc#procedure_db_clearquerycaches[`db.clearQueryCaches()`]::
 Clear all query caches.
 Does not change the database statistics.
 +
@@ -117,7 +117,7 @@ Does not change the database statistics.
 CALL db.clearQueryCaches()
 ----
 
-xref:reference/procedures.adoc#procedure_db_prepareforreplanning[`db.prepareForReplanning()`]::
+xref:procedures.adoc#procedure_db_prepareforreplanning[`db.prepareForReplanning()`]::
 Completely recalculates all database statistics to be used for any subsequent query planning.
 +
 The procedure triggers an index resampling, waits for it to complete, and clears all query caches.
@@ -134,4 +134,4 @@ For more information, see:
 
 * link:{neo4j-docs-base-uri}/cypher-manual/{page-version}/query-tuning#cypher-replanning[Cypher manual -> Cypher replanning]
 * link:{neo4j-docs-base-uri}/cypher-manual/{page-version}/execution-plans[Cypher manual -> Execution plans]
-* xref:reference/procedures.adoc[Procedures]
+* xref:procedures.adoc[Procedures]
diff --git a/modules/ROOT/pages/procedures.adoc b/modules/ROOT/pages/procedures.adoc
diff --git a/modules/ROOT/pages/reference/index.adoc b/modules/ROOT/pages/reference/index.adoc

Original file line number	Diff line number	Diff line change
`@@ -85,7 +85,7 @@ Old transaction logs cannot be safely archived or removed by external jobs since`
`85`	`85`	`Log pruning is called only after checkpoint completion to ensure at least one checkpoint and points to a valid place in the transaction log data.`
`86`	`86`	`In reality, this means that all transaction logs created between checkpoints are kept for some time, and only after a checkpoint, the pruning strategy removes them.`
`87`	`87`	`For more details on how to speed up checkpointing, see xref:database-internals/checkpointing.adoc#transaction-logging-log-pruning[Configure log pruning].`
`88`		-To force a checkpoint, run the procedure xref:reference/procedures.adoc#procedure_db_checkpoint[`CALL db.checkpoint()`].
	`88`	+To force a checkpoint, run the procedure xref:procedures.adoc#procedure_db_checkpoint[`CALL db.checkpoint()`].
`89`	`89`	`+`
`90`	`90`	`[NOTE]`
`91`	`91`	`====`