# Runtime Variables

## Runtime Variables

A powerful feature that allows dynamic configuration. The used parts will be replaced at runtime with the corresponding values. So you could name your target object `{target_schema}.{stream_schema}_{stream_table}`, and at runtime it will be formatted correctly as depicted below.

* **`source_account`**: the name of the account of the source connection (when source conn is AZURE)
* **`source_bucket`**: the name of the bucket of the source connection (when source conn is GCS or S3)
* **`source_container`**: the name of the container of the source connection (when source conn is AZURE)
* **`source_name`**: the name of the source connection
* **`stream_file_folder`**: the file parent folder name of the stream (when source is a file system)
* **`stream_file_name`**: the file name of the stream (when source is a file system)
* **`stream_file_ext`**: the file extension of the stream (when source is a file system)
* **`stream_file_path`**: the file path of the stream (when source is a file system)
* **`stream_name`**: the name of the stream
* **`stream_schema` / `stream_schema_lower` / `stream_schema_upper`**: the schema name of the source stream (when source is a database)
* **`stream_table` / `stream_table_lower` / `stream_table_upper`**: the table name of the source stream (when source is a database)
* **`stream_full_name`**: the full qualified table name of the source stream (when source is a database)
* **`target_account`**: the name of the account of the target connection (when target is AZURE)
* **`target_bucket`**: the name of the bucket of the target connection (when target is GCS or S3)
* **`target_container`**: the name of the container of the target connection (when target is AZURE)
* **`target_name`**: the name of the target connection
* **`target_schema`**: the default target schema defined in connection (when target is a database)
* **`object_schema`**: the target object table schema (when target is a database)
* **`object_table`**: the target object table name (when target is a database)
* **`object_full_name`**: the target object full qualified table name (when target is a database)
* **`object_name`**: the target object name

#### Timestamp Patterns

* **`run_timestamp`**: The run timestamp of the task (`2006_01_02_150405`)
* **`YYYY`**: The 4 digit year of the run timestamp of the task
* **`YY`**: The 2 digit year of the run timestamp of the task
* **`MMM`**: The abbreviation of the month of the run timestamp of the task
* **`MM`**: The 2 digit month of the run timestamp of the task
* **`DD`**: The 2 digit day of the run timestamp of the task
* **`HH`**: The 2 digit 24-hour of the run timestamp of the task
* **`hh`**: The 2 digit 12-hour of the run timestamp of the task
* **`mm`**: The 2 digit minute of the run timestamp of the task
* **`ss`**: The 2 digit second of the run timestamp of the task

#### Partition Patterns

This only applies when writing parquet files. You must specified the `update_key` along with a `part_` variable in the `object_name`, for example: `object: my/folder/{part_year_month}/{part_day}`.

* **`part_year`**: The 4 digit year partition value of the `update_key`.
* **`part_month`**: The 2 digit month partition value of the `update_key`.
* **`part_year_month`**: Combination of the 4 digit year and the 2 digit month partition values of the `update_key` (e.g. `2024-11` as one value).
* **`part_day`**: The 2 digit day partition value of the `update_key`.
* **`part_week`**: The ISO-8601 2 digit week partition value of the `update_key`.
* **`part_hour`**: The 2 digit hour partition value of the `update_key`.
* **`part_minute`**: The 2 digit minute partition value of the `update_key`.

{% hint style="warning" %}
When using partition patterns, by default, sling will set the `write_partition_columns true` so that duckdb includes the partition columns in the dataset. When setting `write_partition_columns` as `true`, the way DuckDB writes the parquet schema may cause some issues with other tools reading the data at folder level (see [here](https://github.com/slingdata-io/sling-cli/issues/634) for more details). If you'd like to disable this behavior, set environment variable `DUCKDB_WRITE_PARTITION_COLS=false` (applies to version *1.4.20+*).
{% endhint %}

## Environment Variables

Sling also allows you to pass-in environment variables in order to further customize configurations in a scalable manner. We are then able to reuse them in various places in our config files.

### Definition

A convenient way to embed global variables is in the `env.yaml` file. You could also simply define it in the environment, the traditional way.

{% code title="env.yaml" %}

```yaml
connections:
  MYSQL:
    type: mysql
  S3_ZONE_A:
    type: s3

# this sets environment variables in sling process
variables:
  path_prefix: /my/path/prefix
  schema_name: main
  SLING_CLI_TOKEN: xxxxxxxxxxxxxxxx  # picked up machine wide
  SLING_LOG_DIR: ~/.sling/logs
```

{% endcode %}

### Replication

Below we are displaying the full use of Environment Variables as well as [Runtime Vars](#runtime-variables) (such as `stream.schema`, `stream.table`, `YYYY`, `MM` and `DD`).

{% code title="replication.yaml" overflow="wrap" %}

```yaml
source: MYSQL
target: S3_ZONE_A

defaults:
  # {path_prefix} here is filled in from env var
  object: {path_prefix}/{stream_schema}/{stream_table}/{YYYY}_{MM}_{DD}.parquet
  target_options:
    format: parquet

streams:

  # all tables in schema
  my_schema.*:
    # overwrites default object
    object: {stream_schema}/{stream.table}/{YYYY}_{MM}_{DD}/
    target_options:
      file_max_rows: 400000 # will split files into folder
  
  mysql.my_table:
    sql: |
      select * from mysql.my_table
      where date between '{start_date}' and '{end_date}'

env:
  # ${path_prefix} pulls from environment variables in sling process or env
  path_prefix: '${path_prefix}' # From env.yaml (not in Environment)
  start_date: '${START_DATE}'   # From Environment
  end_date: '${END_DATE}'       # From Environment
```

{% endcode %}

## Global Environment Variables

Sling utilizes global environment variables to further configure the load behavior. You can simply define them in your environment, the `env.yaml` file or the `env` section in a task or replication. See [Global Environment Variables](/sling-cli/variables.md) for more details.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.slingdata.io/concepts/replication/runtime-variables.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.