dbt Core: dbt version 0.2.3.0

## dbt v0.2.3.0 Version 0.2.3.0 of dbt comes with the following updates: #### 1. Fix: Flip referential integrity arguments (breaking) Referential integrity validations in a `schema.yml` file were previously defined relative to the _parent_ table: ``` yaml account: constraints: relationships: - {from: id, to: people, field: account_id} ``` Now, these validations are specified relative to the _child_ table ``` yaml people: constraints: relationships: - {from: account_id, to: accounts, field: id} ``` For more information, run `dbt test -h` #### 2. Feature: seed tables from a CSV Previously, auxiliary data needed to be shoehorned into a view comprised of union statements, eg. ``` sql select 22 as "type", 'Chat Transcript' as type_name, 'chatted via olark' as event_name union all select 21, 'Custom Redirect', 'clicked a custom redirect' union all select 6, 'Email', 'email sent' union all ... ``` That's not a scalable solution. Now you can load CSV files into your data warehouse: 1. Add a CSV file (with a header) to the `data/` directory 2. Run `dbt seed` to create a table from the CSV file! 3. The table name with be the filename (sans `.csv`) and it will be placed in your `run-target`'s schema Subsequent calls to `dbt seed` will truncate the seeded tables (if they exist) and re-insert the data. If the table schema changes, you can run `dbt seed --drop-existing` to drop the table and recreate it. For more information, run `dbt seed -h` #### 3. Feature: compile analytical queries Versioning your SQL models with dbt is a great practice, but did you know that you can also version your analyses? Any SQL files in the `analysis/` dir will be compiled (ie. table names will be interpolated) and placed in the `target/build-analysis/` directory. These analytical queries will _not_ be run against your data warehouse with `dbt run` -- you should copy/paste them into the data analysis tool of your choice. #### 4. Feature: accepted values validation In your `schema.yml` file, you can now add `accepted-values` validations: ``` yaml accounts: constraints: accepted-values: - {field: type, values: ['paid', 'free']} ``` This test will determine how many records in the `accounts` model have a `type` other than `paid` or `free`. #### 5. Feature: switch profiles and targets on the command line Switch between profiles with `--profile [profile-name]` and switch between run-targets with `--target [target-name]`. Targets should be something like "prod" or "dev" and profiles should be something like "my-org" or "my-side-project" ``` yaml side-project: outputs: prod: type: redshift host: localhost port: 5439 user: Drew pass: dbname: data_generator schema: ac_drew dev: type: redshift host: localhost port: 5439 user: Drew pass: dbname: data_generator schema: ac_drew_dev run-target: dev ``` To compile models using the `dev` environment of my `side-project` profile: `$ dbt compile --profile side-project --target dev` or for `prod`: `$ dbt compile --profile side-project --target prod` You can also add a "profile' config to the `dbt_config.yml` file to fix a dbt project to a specific profile: ``` yaml ... test-paths: ["test"] data-paths: ["data"] # Fix this project to the "side-project" profile # You can still use --target to switch between environments! profile: "side-project" model-defaults: .... ```