DBT — как создавать таблицы пространств имен, созданные разными версиями проекта, без схем?

Допустим, у меня есть проект в dbt. Когда я запускаю его, он генерирует кучу таблиц. Теперь я хочу изменить базовый SQL и посмотреть, что произойдет с этими таблицами, чем они отличаются от того, что было до изменения. Поэтому я хочу иметь возможность сравнивать все таблицы, сгенерированные старой версией, со всеми таблицами, сгенерированными новой версией. В идеале я хотел бы, чтобы метод работал для любого количества версий, а не только для двух. В основном вопрос заключается в том, как поместить каждую версию в свое собственное пространство имен.

Способ 1: запустить новую версию проекта в новой схеме, чтобы я мог сравнить old.foo с new.foo. Но получение другой схемы от администраторов базы данных — болезненный процесс.

Способ 2: иметь обе версии в одной и той же схеме, но добавить префикс, например new_, к имени таблицы для новой версии. Итак, в старой версии есть таблица foo, в новой — new_foo, а я сравниваю foo с new_foo.

Есть ли удобный способ сделать метод 2 в dbt? Есть ли третий метод, который я должен рассмотреть? Или я делаю что-то в корне неправильное, чтобы вообще оказаться в такой ситуации? Кажется, что это не должно быть такой редкой проблемой, но я не могу найти никакой информации о том, что я могу сделать в этой ситуации.

Я определенно рекомендую метод 1 вместо метода 2. Возможно, вы даже захотите иметь другую базу данных, одну для производства и одну для подготовки. Я не понимаю, почему создание схем должно быть ограничено вашими администраторами. В любом случае вам нужно иметь привилегии создания схемы с вашей ролью DBT. Кажется слишком контролирующим, чтобы сделать создание схемы проблемой. Каждый разработчик должен иметь свою собственную схему для целей разработки.

Adam Kipnis 11.02.2023 02:51

Я работаю в крупной компании, и это так. Они ни за что не дадут мне права на создание схемы. Возможно, однажды у нас будет промежуточная база данных с большей гибкостью.

Paul 11.02.2023 03:42
ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
Понимание Python и переход к SQL
Понимание Python и переход к SQL
Перед нами лабораторная работа по BloodOath:
1
2
58
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Один из возможных способов сделать это — переопределить макрос псевдонима по умолчанию. Макрос вызывается, даже если в конфигурации не определен псевдоним, поэтому вы можете использовать это как возможность переименовать целевую таблицу.

В приведенной ниже версии к любой модели, для которой не задан псевдоним в конфигурации, будет добавляться имя целевого профиля, если запуск не соответствует профилю prod.

{% macro generate_alias_name(custom_alias_name=none, node=none) -%}
    {%- if target.name != 'prod' and custom_alias_name is none -%}
        {{ target.name ~ "_" ~ node.name }}
    {%- elif target.name == 'prod' -%}
        {{ node.name }}
    {%- else -%}
        {{ custom_alias_name | trim }}
    {%- endif -%}
{%- endmacro %}

Если ваша модель foo.sql и вы запускаете ее для профиля с именем «prod», таблица будет foo. Если вы запустите его против «dev», это будет dev_foo. Если у вашей модели есть псевдоним, то имя псевдонима будет иметь приоритет независимо от целевого профиля. Вы можете решить, хотите ли вы включить специальное поведение, если модель имеет псевдоним. Просто измените блок else.

Другие вопросы по теме