custom schemas

[drewbanin]

Specify custom schemas for models

TODO:

• add integration tests
  • in-config
  • in-project
  • in-project overridden by in-config
• make sure this works with temp tables (I think it does)
• docs docs docs

Usage
This branch uses a macro to generate model schema names, and users can override this macro to create alternative schema behavior.

This branch uses a macro called generate_schema_name to get a schema name for a model. By default, this macro just concatenates the schema defined in the active profile with the schema defined in the model config, if any.

To override this behavior, users can create a macro in their own project called generate_schema_name. In practice, this would look like:

-- All models will be generated in the `public` schema, always.
{% macro generate_schema_name(schema_name) -%}
    public
{%- endmacro %}

A more useful strategy uses the profile schema in development, and the custom model schema in production. The macro to do that looks like this:

{% macro generate_schema_name_for_env(custom_schema_name=none) -%}
    {%- set default_schema = target.schema -%}
    {%- if target.name == 'prod' and custom_schema_name is not none -%}
        {{ custom_schema_name | trim }}
    {%- else -%}
        {{ default_schema }}
    {%- endif -%}
{%- endmacro %}

Since I think this will be a common strategy, I went ahead and added this to the global project too. So, to use the "default in dev, custom in prod" strategy, users should create macros/generate_schema.sql with these contents:

{% macro generate_schema_name(schema_name) -%}
    {{ generate_schema_name_for_env(schema_name) }}
{%- endmacro %}

Docs: https://dbt.readme.io/v0.9/docs/using-custom-schemas

[cmcarthur]

@drewbanin this code looks great. I think this is OK to merge with the current naming conventions if you put three things in the docs:

• how to build everything in one schema
• how to build in multiple schemas using a prefix
• how to use one schema in dev and multiple in prod

in addition to generally documenting what the schema and schema_prefix fields do

[cmcarthur]

I love the approach here. What is the argument passed to the generate_schema_name? I had imagined this would work something like:

{% macro generate_schema_name() %}
  {% set default_schema = target.schema %}
  {% set model_schema = this.schema %}
  ... logic ...
{% endmacro %}

[drewbanin]

@cmcarthur I don't think we have access to this when we call that macro in the parsing stage. The arg to generate_schema_name is the custom schema specified for the model being parsed

[drewbanin]

@cmcarthur can you just give this a quick final pass?

[cmcarthur]