[Bug]: Materialize as table in a Dremio space sub folder fails

[maxfirman]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

If you define a model materialisation strategy to materialized='table' then it creates the table in the object_storage_source at the object_storage_path and a corresponding view in the dremio_space. The creation of the view fails if the model's schema is configured as a subfolder and that subfolder does not already exist.

It is possible to work around this bug by creating another dummy model in the same schema with materialisation strategy materialized='view'.

Expected Behavior

The view created by the materialized='table' strategy should create the subfolder if it does not exist already.

Steps To Reproduce

Create a simple model to materialize as a table in a subfolder:

{{ config(materialized='table', schema='foo.bar') }}
select 1 as a

Execute

dbt run

Observe error:

10:48:03    ERROR: NamespaceNotFoundException: one or more elements on the path are not found in namespace: "<dremio_space>".foo.bar.baz

Environment

- OS: Ubuntu
- dbt-dremio: 1.5.0
- Dremio Software: 24.0.2

Relevant log output

No response

[mxmarg]

I can confirm that this bug exists and I have used the same workaround of creating a simple "init" view in the same space folder before materialising the table

[mxmarg]

As described by @fabrice-etanchaud in his comment (#192 (comment)), another workaround is to set the dbt-dremio connector's twin_strategy to either allow or prevent, instead of the default clone. This will stop dbt from attempting to create an additional view on top of the created table.

Example:

{{ config(
    twin_strategy="allow",
    materialized="table"
) }}
SELECT 1