[Bug]: INSERT statement's target must be a table

[sfc-gh-afedorov]

Overview

error

03:13:50  on-run-end failed, error:
03:13:50   001759 (42601): SQL compilation error:
03:13:50  INSERT statement's target must be a table

when I first install the package

How to reproduce

follow installation instructions, note that the model is materialized as a view

03:13:44  3 of 34 START sql view model afedorov.model_executions ......................... [RUN]

Expected behaviour

for the model executions to be a table and the run to succeed

Screenshots

Environment

Results of running dbt --version:

% dbt --version
Core:
  - installed: 1.4.5
  - latest:    1.4.5 - Up to date!

Plugins:
  - snowflake: 1.4.2 - Up to date!

Please paste the contents of your packages.yml file here:

version: 2.0
require-dbt-version: [">=1.4.4", "<2.0.0"]
config-version: 2

# This setting configures which "profile" dbt uses for this project. Profiles contain
# database connection information, and should be configured in the ~/.dbt/profiles.yml file
profile: "default"

# These configurations specify where dbt should look for different types of files.
# The `source-paths` config, for example, states that source models can be found
# in the "models/" directory. You probably won't need to change these!
model-paths: ["models"]
analysis-paths: ["analysis"]
test-paths: ["tests"]
seed-paths: ["data"]
macro-paths: ["macros"]

target-path: "target" # directory which will store compiled SQL files
clean-targets: # directories to be removed by `dbt clean`
  - "target"
  - "dbt_packages"

seeds:
  #...

models:
  +materialized: view
  #...

vars:
  #...

on-run-start:
  #...

on-run-end:
  #...
  - "{{ dbt_artifacts.upload_results(results) }}"

[jaypeedevlin]

At a guess, does your dbt_project.yml look like this:

models:
  materialization: view

If so you may be overriding the materialisation in the package, I would try changing it to:

models:
  your_project_name:
    materialization: view

and it should fix it.

[sfc-gh-afedorov]

That is indeed the case, thank you kindly. Could you explain exactly how this works, or help me find the pertinent docs?

I'm guessing there's a single global namespace that the main project can use to define a default materializations for all packages, but I'm not sure if this is intended dbt behavior that the packages appears unable to override the materializations defined there — it seems like more specific declarations should have precedence, as they do in other hierarchical attribute definitions like CSS.

[jaypeedevlin]

https://docs.getdbt.com/reference/resource-configs/resource-path