# Config.ini

The config.ini is the main spot for users to configure their Turbovault4dbt experience. It features both general and adapter-specific parameters. You are good to go to directly use the template file inside this repository, and simply fill out everything that you want to use or change. **It is not required to remove the parameters of unused adapters.*This is what the config.ini template looks like:

    [BigQuery]
    stage_schema =
    rdv_schema =
    metadata_dataset =
    project_id =
    hashdiff_naming = hd_@@SatName
    model_path = ../models/BigQuery/@@entitytype/@@SourceSystem/
    credential_path =
    [Google Sheets]
    stage_schema =
    rdv_schema =
    hashdiff_naming = hd_@@SatName
    model_path = ../models/GoogleSheets/@@entitytype/@@SourceSystem/
    sheet_url =
    gcp_oauth_credentials =
    [Excel]
    stage_schema = 
    rdv_schema =
    hashdiff_naming = hd_@@SatName
    model_path = ../models/Excel/@@entitytype/@@SourceSystem/
    excel_path =
    [Snowflake]
    stage_schema =
    rdv_schema = 
    hashdiff_naming = hd_@@SatName
    model_path = ../models/Snowflake/@@entitytype/@@SourceSystem/
    account_identifier =
    database =
    warehouse =
    role =
    meta_schema =
    credential_path =

## General Parameters

<div align="center" >
<table border="1" cellpadding = "5">

<tr>
<th>Parameter</th>
<th>Explanation</th>
</tr>
<tr>
<td>stage_schema</td>
<td>Name of the schema inside the target database which should hold your stages. Note: Turbovault4dbt does not connect to your target database, it only generates the dbt models for your dbt project, so this will affect the configuration for each staging model.  </td>
</tr>
<tr>
<td>rdv_schema</td>
<td>Since we recommend storing the Raw Vault inside a different schema than the stages, you can configure a separate schema for Raw Vault objects here. The effect is the same as of the parameter "stage_schema". </td>
</tr>
<tr>
<td>hashdiff_naming</td>
<td>Turbovault4dbt automatically generates the names of hashdiff columns. For this, it applies configurable naming conventions. Since the name of a hashdiff should contain the name of the belonging satellite, you are able to use the placeholder "@@SatName" within the parameter. If you want to automatically apply the prefix "hd_" for your hashdiff names, this parameter would be set to "hd_@@SatName". </td>
</tr>
<tr>
<td>model_path</td>
<td>The local path within your system where the generated models should be stored at. It must be set to a local path based on the location of the "turbovault_<adapter>.py" files. We recommend storing the models outside of your Turbovault directory. You should use the two placeholders "@@entitytype" and "@@SourceSystem" to organize your models for a better overview. Turbovault4dbt automatically includes the current timestamp inside the output directory structure to enable full historicization. </td>
</tr>

</table>
</div>

## Adapter Configuration ParametersFor adapter-specific parameters check out the guide on [how to connect to your metadata](https://github.com/ScalefreeCOM/turbovault4dbt/wiki/connect-to-metadata).
Parameter	Explanation
stage_schema	Name of the schema inside the target database which should hold your stages. Note: Turbovault4dbt does not connect to your target database, it only generates the dbt models for your dbt project, so this will affect the configuration for each staging model.
rdv_schema	Since we recommend storing the Raw Vault inside a different schema than the stages, you can configure a separate schema for Raw Vault objects here. The effect is the same as of the parameter "stage_schema".
hashdiff_naming	Turbovault4dbt automatically generates the names of hashdiff columns. For this, it applies configurable naming conventions. Since the name of a hashdiff should contain the name of the belonging satellite, you are able to use the placeholder "@@SatName" within the parameter. If you want to automatically apply the prefix "hd_" for your hashdiff names, this parameter would be set to "hd_@@SatName".
model_path	The local path within your system where the generated models should be stored at. It must be set to a local path based on the location of the "turbovault_.py" files. We recommend storing the models outside of your Turbovault directory. You should use the two placeholders "@@entitytype" and "@@SourceSystem" to organize your models for a better overview. Turbovault4dbt automatically includes the current timestamp inside the output directory structure to enable full historicization.