Can you configure the dbt transformer somehow that...
# plugins-dbt
j
Can you configure the dbt transformer somehow that it doesn’t prepend the schema set in meltano.yml to every schema?
e
Hi @Johan Vrolix! What have you tried so far?
j
Apart from omitting the schema in the meltano configuration and setting schemas in the dbt project yaml, nothing really comes to mind
e
Ok, so how do your
meltano.yml
and
dbt_project.yml
look like?
j
meltano.yml
Copy code
version: 1
env:
  DBT_CLEAN_PROJECT_FILES_ONLY: 'false'
default_environment: dev
project_id: e7660772-c6df-4e04-9a94-21281710aba6
environments:
- name: dev
- name: staging
- name: prod
plugins:
  extractors:
  - name: tap-postgres
    variant: meltanolabs
    pip_url: git+<https://github.com/MeltanoLabs/tap-postgres.git>
  - name: source-northwind
    inherit_from: tap-postgres
    config:
      host: localhost
      user: northwind
      database: northwind
      port: 5435
    select:
    - public-shippers.*
    - public-suppliers.*
    - public-customers.*
    - public-employees.*
    - public-orders.*
    - public-order_details.*
    - public-products.*
    - public-categories.*
    - public-territories.*
    - public-employee_territories.*
    - public-us_states.*
    - public-customer_demographics.*
    - public-customer_customer_demo.*
    - public-region.*

  - name: tap-rest-api-msdk
    variant: widen
    pip_url: tap-rest-api-msdk
  - name: ellie-metadata
    inherit_from: tap-rest-api-msdk
    config:
      api_url: <https://optimalist.ellie.ai>
      streams:
        - name: metadata
          path: /api/v1/models/$ELLIE_ID
          primary_keys: ["model_modelId"]
  loaders:
  - name: target-postgres
    variant: meltanolabs
    pip_url: meltanolabs-target-postgres
  - name: target-dwh
    inherit_from: target-postgres
    config:
      host: localhost
      user: dwh
      database: dwh
      port: 5433
      threads: 4
  utilities:
  - name: dbt-postgres
    variant: dbt-labs
    pip_url: dbt-core dbt-postgres meltano-dbt-ext~=0.3.0
    config:
      host: localhost
      port: 5433
      user: dwh
      schema: dwh
      database: dwh
dbt_project.yml
Copy code
name: my_meltano_project
version: '1.0'
profile: meltano
config-version: 2
require-dbt-version: [">=1.0.0", "<2.0.0"]
flags:
  send_anonymous_usage_stats: False
  use_colors: True
model-paths:
  - models
analysis-paths:
  - analysis
test-paths:
  - tests
seed-paths:
  - data
macro-paths:
  - macros
snapshot-paths:
  - snapshots
log-path: logs
packages-install-path: dbt_packages
clean-targets:
  - ../.meltano/transformers/dbt/target
  - dbt_packages
  - logs

models:
  my_meltano_project:
    staging_northwind:
      +schema: staging_northwind
      +materialized: view
    raw_vault:
      +schema: rdv
      +materialized: incremental
    business_vault:
      +schema: bdv
      +materialized: view
    information_marts:
      +schema: im
      +materialized: view
    ellie:
      +schema: ellie_metadata
      +materialized: view
e
So what's the problematic prefix?
j
The ‘dwh’ schema configured in meltano.yml gets prefixed when building the dbt models. Eg. For the raw_datavault objects the schema becomes dwh_rdv
m
We just overrode dbt’s builtin
generate_schema_name
macro:
Copy code
{% macro generate_schema_name(custom_schema_name, node) -%}
    {%- set default_schema = target.schema -%}
    {%- if custom_schema_name is none -%}
        {{ default_schema }}
    {%- else -%}
        {{ custom_schema_name | trim }}
    {%- endif -%}
{%- endmacro %}
j
So next release?
Ah, you mean you did it within your project?
m
Yes, if you define your own macro with the same name as a builtin macro, your locally defined one will take precedence.
j
Cool, thanks
👍 2