Closed mcnick closed 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 🙂
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).
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
Then
query_path
formodel_a
as given in the manifest file istarget/compiled/<project_name>/models/model_a.sql
however to be specified from the repository root it should betransform/target/compiled/<project_name>/models/model_a.sql
Idea
One could e.g. pass
dbt_project.yml
instead of/additionally tomanifest.json
toSQLMockConfig
:dbt_project.yml
.target-path
or directly passed in case a different one was passed to the--target-path
parameter on the dbt rundbt_project.yml
and thequery_path
provides the correct path from the repository root