DeepLcom / sql-mock

A Python library to test your SQL models using mocked input data
MIT License
33 stars 5 forks source link

dbt project in subdirectory #33

Closed mcnick closed 8 months ago

mcnick commented 8 months ago

Problem

The dbt query_paths in the manifest file are only provided relative to the dbt project root. In the case of a repository where the dbt project is in a subdirectory using only the query_path to retrieve the query does not work in dbt.dbt_model_meta. In this case the path to the dbt project root has to be prepended to the query_path.

Example

Consider the following structure for a repository

repository
├── other_folders
├── transform
│   ├── models
│   │   └── model_a.sql
│   ├── target
│   │   ├── compiled
│   │   │   └── <project_name>
│   │   │   │   └── models
│   │   │   │   │   └── model_a.sql
│   │   └── manifest.json
│   └── dbt_project.yml
└── other_files

Then query_path for model_a as given in the manifest file is target/compiled/<project_name>/models/model_a.sql however to be specified from the repository root it should be transform/target/compiled/<project_name>/models/model_a.sql

Idea

One could e.g. pass dbt_project.yml instead of/additionally to manifest.json to SQLMockConfig:

Somtom commented 8 months ago

Sounds like a reasonable improvement. Would you mind adding a specific example that we can use to reproduce it? I think I understand what you mean but this would make things clearer 🙂

Somtom commented 8 months ago

Thanks for adding more context. At first sight it feels that it might make most sense to pass the path to the dbt_project.yml (instead of the manifest.json path since to my research it should always be populated in the target directory specified). Technically it could be enough to have the path to the target directory ( since there we will find the manifest file). However, parsing the dbt_project.yml could generate benefits since we have access to more information (e.g. variables that we might want to automatically provide to the template renderer).