jthandy

with staged_events as (
    select * from  {{ ref('snowplow_events_base') }}
),

context as (

    select 
        event_id as root_id, 
        c.value:data:id::string as id,
        collector_tstamp

jthandy

jthandy

with orders as (
    select
        order_id,
        json_extract_path_text(json_text, 'items', true ) as items
    from flatten_test
),

numbers as (
    select * from numbers
),

jthandy

jthandy

jthandy

jthandy

create table dbt_jthandy.flatten_test (
    order_id int, 
    json_text varchar(1000)
    )
;

insert into dbt_jthandy.flatten_test
  (order_id, json_text) 
values
  (1, '{  

jthandy

{% macro source_select_sql(relation, column_name) %}
    select {{column_name}} as f from {{relation}}
{% endmacro %}


{% macro single_pass_stats(relation, column_name) %}
    {%- call statement('single_pass_column_stats', fetch_result=True) -%}

        with source as ( {{ fishtown_internal_analytics.source_select_sql(relation, column_name) }} ),
        single_pass_stats as (

jthandy

Running vacuum and analyze in Sinter

dbt and Sinter have the ability to run regular Redshift maintenance jobs. It's great to set these up early on in a project so that things stay clean as the project grows, and implementing these jobs in Sinter allows the same easy transparency and notifications as with your other dbt jobs.

This document will go through the specific steps necessary to configure vacuum and analyze jobs in the current version of dbt and Sinter. In the future, there will likely be a more idiomatically consistent way to express this logic using native dbt operations. Currently, this does work even if it is not elegant.

Step 1: Create the macros

macros/redshift_maintenance.sql

jthandy

with discounts as (

    select * from {{ref('stripe_discounts')}}

),

invoice_items as (

    select * from {{ref('stripe_invoice_items')}}