diff --git a/pages/advanced-algorithms/available-algorithms/migrate.mdx b/pages/advanced-algorithms/available-algorithms/migrate.mdx index 4609c2c63..884b57e6d 100644 --- a/pages/advanced-algorithms/available-algorithms/migrate.mdx +++ b/pages/advanced-algorithms/available-algorithms/migrate.mdx @@ -32,6 +32,19 @@ filter, and convert relational data into a graph format. | **Implementation** | Python | | **Parallelism** | sequential | + +When running multiple migrations against the same source, avoid repeating the `config` map in every call. +Use [server-side parameters](/database-management/server-side-parameters) to store the connection config once +and reference it as `$config` across all your queries: + +```cypher +SET GLOBAL PARAMETER pg_config = {user: 'memgraph', password: 'password', host: 'localhost', database: 'demo_db'}; + +CALL migrate.postgresql('users', $pg_config) YIELD row CREATE (u:User {id: row.id}); +CALL migrate.postgresql('orders', $pg_config) YIELD row CREATE (o:Order {id: row.id}); +``` + + --- ## Procedures diff --git a/pages/ai-ecosystem/graph-rag/atomic-pipelines.mdx b/pages/ai-ecosystem/graph-rag/atomic-pipelines.mdx index 5955144d8..af2e7a8b2 100644 --- a/pages/ai-ecosystem/graph-rag/atomic-pipelines.mdx +++ b/pages/ai-ecosystem/graph-rag/atomic-pipelines.mdx @@ -57,9 +57,9 @@ Offer the ability to compute embeddings during the preprocessing or retrieval stages. 11. [`llm.complete`](/advanced-algorithms/available-algorithms/llm) function: Allows you to call any LLM under any given Cypher query. -12. Server-side parameters: Could be used for many different things, but in this -context, the parameters help you with managing configuration under any given -query or pipeline. +12. [Server-side parameters](/database-management/server-side-parameters): Could +be used for many different things, but in this context, the parameters help you +managing configuration under any given query or pipeline. ## Question and Pipeline Types @@ -107,4 +107,4 @@ exists, it synthesizes what is missing or not well-covered. Example use cases: - **Publishing**: *"I want to write a book, which important topics in this domain are not yet well covered in the existing literature?"* -![atomic_graphrag_pipelines](/pages/ai-ecosystem/graph-rag/atomic-pipelines/atomic-graphrag-pipelines.png) \ No newline at end of file +![atomic_graphrag_pipelines](/pages/ai-ecosystem/graph-rag/atomic-pipelines/atomic-graphrag-pipelines.png) diff --git a/pages/database-management/_meta.ts b/pages/database-management/_meta.ts index cb0c5a2e0..801f27ca3 100644 --- a/pages/database-management/_meta.ts +++ b/pages/database-management/_meta.ts @@ -9,6 +9,7 @@ export default { "monitoring": "Monitoring", "multi-tenancy": "Multi-tenancy", "query-metadata": "Query metadata", + "server-side-parameters": "Server-side parameters", "server-stats": "Server stats", "ssl-encryption": "SSL encryption", "system-configuration": "System configuration" diff --git a/pages/database-management/authentication-and-authorization/query-privileges.mdx b/pages/database-management/authentication-and-authorization/query-privileges.mdx index d24575f88..ba0e6fdc3 100644 --- a/pages/database-management/authentication-and-authorization/query-privileges.mdx +++ b/pages/database-management/authentication-and-authorization/query-privileges.mdx @@ -124,6 +124,9 @@ Memgraph's privilege system controls access to various database operations throu | `DATA DIRECTORY LOCK STATUS` | `DURABILITY` | `DATA DIRECTORY LOCK STATUS` | | `FREE MEMORY` | `FREE_MEMORY` | `FREE MEMORY` | | `SHOW CONFIG` | `CONFIG` | `SHOW CONFIG` | +| `SET [GLOBAL] PARAMETER` | `SERVER_SIDE_PARAMETERS` | `SET GLOBAL PARAMETER x = 'value'` | +| `UNSET [GLOBAL] PARAMETER` | `SERVER_SIDE_PARAMETERS` | `UNSET PARAMETER x` | +| `SHOW PARAMETERS` | `SERVER_SIDE_PARAMETERS` | `SHOW PARAMETERS` | | `CREATE TRIGGER` | `TRIGGER` | `CREATE TRIGGER ...` | | `DROP TRIGGER` | `TRIGGER` | `DROP TRIGGER ...` | | `SHOW TRIGGERS` | `TRIGGER` | `SHOW TRIGGERS` | diff --git a/pages/database-management/configuration.mdx b/pages/database-management/configuration.mdx index 6fe01b68d..63b982f48 100644 --- a/pages/database-management/configuration.mdx +++ b/pages/database-management/configuration.mdx @@ -342,6 +342,10 @@ If you want to change a value for a specific setting, following query should be SET DATABASE SETTING "setting.name" TO "some-value"; ``` +For reusable query values accessed as `$name`, see +[Server-side parameters](/database-management/server-side-parameters). Unlike +database settings, server-side parameters are resolved during query execution. + ### Multitenancy and configuration If you are using a multi-tenant architecture, all isolated databases share diff --git a/pages/database-management/server-side-parameters.mdx b/pages/database-management/server-side-parameters.mdx new file mode 100644 index 000000000..361f683e2 --- /dev/null +++ b/pages/database-management/server-side-parameters.mdx @@ -0,0 +1,142 @@ +--- +title: Server-side parameters +description: Configure and reuse server-side parameters in Memgraph with database or global scope. +--- + +# Server-side parameters + +Server-side parameters are named values stored by Memgraph and reusable in +queries through `$parameterName`, just like user-provided parameters. + +They are useful when you want reusable defaults, while still allowing clients to override values when needed. + +## Parameter scopes + +Server-side parameters support two scopes: + +- **Database scope**: set with `SET PARAMETER ...`; visible only in the current + database. +- **Global scope**: set with `SET GLOBAL PARAMETER ...`; visible across + databases. + +When you run `SHOW PARAMETERS`, Memgraph returns: +- all global parameters +- parameters from the current database + +## Resolution order + +When a query uses `$name`, values are resolved in this order: + +1. user-provided query parameter (from the client) +2. database-scoped server-side parameter +3. global server-side parameter + +This means: +- user-provided parameters are preferred over server-side parameters +- database-scoped server-side parameters are preferred over global ones + +## Set a parameter + +Use `SET PARAMETER` for database scope, or `SET GLOBAL PARAMETER` for global +scope. + +```opencypher +SET PARAMETER x = 'db_value'; +SET GLOBAL PARAMETER x = 'global_value'; +``` + +You can set the value from: +- a literal +- a user-provided parameter (for example `$config`) +- a map value + +```opencypher +SET GLOBAL PARAMETER app_config = $config; +SET GLOBAL PARAMETER limits = {timeout: 120, mode: 'safe'}; +SET GLOBAL PARAMETER ids = [10, 20, 30]; +``` + +## Unset a parameter + +Remove a parameter by name in either database or global scope. + +```opencypher +UNSET PARAMETER x; +UNSET GLOBAL PARAMETER x; +``` + +## Show parameters + +List current server-side parameters: + +```opencypher +SHOW PARAMETERS; +``` + +Output columns: +- `name`: parameter name +- `value`: stored value (JSON-encoded string form) +- `scope`: `database` or `global` + +## Privileges + +Server-side parameter queries require the `SERVER_SIDE_PARAMETERS` privilege. +See the [Query privileges reference](/database-management/authentication-and-authorization/query-privileges). + +## Use cases + +### Use in queries with `$` + +Once set, server-side parameters are available as `$name` in queries: + +```opencypher +SET GLOBAL PARAMETER tenant = 'acme'; +CREATE (:Account {tenant: $tenant}); +``` + +If the client sends a user parameter with the same name, that user value is +used first: + +```opencypher +SET GLOBAL PARAMETER x = 'server_value'; +CREATE (:Node {property: $x}); +``` + +If the query is run with user parameter `x = 'client_value'`, the node property +will be `'client_value'`. + +### Reusing connection config in data migrations + +The [`migrate` module](/advanced-algorithms/available-algorithms/migrate) procedures accept a `config` map with +connection parameters like `host`, `port`, `user`, and `password`. When running multiple migration queries +against the same source, repeating this map in every call is verbose and error-prone. + +Store the config once as a server-side parameter and reference it with `$config` across all your migration queries: + +```opencypher +SET GLOBAL PARAMETER mysql_config = { + user: 'memgraph', + password: 'password', + host: 'localhost', + database: 'demo_db' +}; +``` + +Then use `$mysql_config` in every migration call instead of repeating the full map: + +```opencypher +CALL migrate.mysql('users', $mysql_config) +YIELD row +CREATE (u:User {id: row.id, name: row.name}); + +CALL migrate.mysql('orders', $mysql_config) +YIELD row +CREATE (o:Order {id: row.id, total: row.total}); + +CALL migrate.mysql('SELECT user_id, order_id FROM user_orders', $mysql_config) +YIELD row +MATCH (u:User {id: row.user_id}), (o:Order {id: row.order_id}) +CREATE (u)-[:PLACED]->(o); +``` + +This works for all `migrate` procedures — `migrate.postgresql()`, `migrate.mysql()`, `migrate.neo4j()`, `migrate.sql_server()`, and others.