diff --git a/_redirects b/_redirects index ab0e4890b0c..b88b420d325 100644 --- a/_redirects +++ b/_redirects @@ -13,8 +13,6 @@ /docs/api-variable /docs/writing-code-in-dbt/api-variable 302 /docs/archival /docs/building-a-dbt-project/archival 302 /docs/artifacts /docs/dbt-cloud/using-dbt-cloud/artifacts 302 -/docs/best-practices /guides/best-practices 302 -/docs/guides/best-practices /guides/best-practices 302 /docs/bigquery-configs /reference/resource-configs/bigquery-configs 302 /docs/building-a-dbt-project/building-models/bigquery-configs /reference/resource-configs/bigquery-configs 302 /docs/building-a-dbt-project/building-models/configuring-models /reference/model-configs @@ -39,7 +37,7 @@ /docs/building-a-dbt-project/using-operations /docs/building-a-dbt-project/hooks-operations 302 /docs/building-a-new-adapter /docs/contributing/building-a-new-adapter 302 /docs/building-models /docs/building-a-dbt-project/building-models 302 -/docs/building-packages /docs/guides/building-packages 302 +/docs/building-packages /guides/legacy/building-packages 302 /docs/centos /dbt-cli/installation 302 /docs/clean /reference/commands/clean 302 /docs/cloud-choosing-a-dbt-version /docs/dbt-cloud/cloud-configuring-dbt-cloud/cloud-choosing-a-dbt-version 302 @@ -70,8 +68,8 @@ /docs/connecting-your-database /docs/dbt-cloud/cloud-configuring-dbt-cloud/connecting-your-database 302 /docs/contributor-license-agreements /docs/contributing/contributor-license-agreements 302 /docs/creating-a-project /docs/building-a-dbt-project/dbt-projects/creating-a-project 302 -/docs/creating-new-materializations /docs/guides/creating-new-materializations 302 -/docs/custom-schema-tests /docs/guides/writing-custom-schema-tests 302 +/docs/creating-new-materializations /guides/legacy/creating-new-materializations 302 +/docs/custom-schema-tests /guides/legacy/writing-custom-generic-tests 302 /docs/dbt-api /docs/running-a-dbt-project/dbt-api 302 /docs/dbt-cloud-enterprise /docs/dbt-cloud/dbt-cloud-enterprise 302 /docs/dbt-cloud/cloud-configuring-repositories /docs/dbt-cloud/cloud-configuring-dbt-cloud/cloud-configuring-repositories 302 @@ -97,10 +95,21 @@ /docs/getting-started-with-jinja /docs/building-a-dbt-project/jinja-macros 302 /docs/global-cli-flags /reference/global-cli-flags 302 /docs/graph /docs/writing-code-in-dbt/jinja-context/graph 302 -/docs/guides/writing-custom-schema-tests /docs/guides/writing-custom-generic-tests -/docs/guides/best-practices /guides/best-practices -/docs/guides/best-practices#choose-your-materializations-wisely /guides/best-practices 302 -/docs/guides/best-practices#version-control-your-dbt-project /guides/legacy/best-practices#version-control-your-dbt-project 302 +/docs/guides/building-packages /guides/legacy/building-packages 302 +/docs/guides/creating-new-materializations /guides/legacy/creating-new-materializations 302 +/docs/guides/debugging-errors /guides/legacy/debugging-errors 302 +/docs/guides/debugging-schema-names /guides/legacy/debugging-schema-names 302 +/docs/guides/getting-help /guides/legacy/getting-help 302 +/docs/guides/managing-environments /guides/legacy/managing-environments 302 +/docs/guides/navigating-the-docs /guides/legacy/navigating-the-docs 302 +/docs/guides/understanding-state /guides/legacy/understanding-state 302 +/docs/guides/videos /guides/legacy/videos 302 +/docs/guides/writing-custom-generic-tests /guides/legacy/writing-custom-generic-tests 302 +/docs/guides/writing-custom-schema-tests /guides/legacy/writing-custom-generic-tests 302 +/docs/guides/best-practices#choose-your-materializations-wisely /guides/legacy/best-practices#choose-your-materializations-wisely 302 +/docs/guides/best-practices#version-control-your-dbt-project /guides/legacy/best-practices#version-control-your-dbt-project 302 +/docs/best-practices /guides/legacy/best-practices 302 +/docs/guides/best-practices /guides/best-practices 302 /docs/hooks /docs/building-a-dbt-project/hooks-operations 302 /docs/init /reference/commands/init 302 /docs/install-from-source /dbt-cli/installation 302 @@ -112,7 +121,7 @@ /docs/log /docs/writing-code-in-dbt/jinja-context/log 302 /docs/macos /dbt-cli/installation 302 /docs/macros /docs/building-a-dbt-project/macros 302 -/docs/managing-environments /docs/guides/managing-environments 302 +/docs/managing-environments /guides/legacy/managing-environments 302 /docs/materializations /docs/building-a-dbt-project/building-models/materializations 302 /docs/model-selection-syntax /reference/node-selection/syntax 302 /docs/modules /docs/writing-code-in-dbt/jinja-context/modules 302 @@ -212,12 +221,12 @@ /docs/using-variables /docs/building-a-dbt-project/building-models/using-variables 302 /docs/var /docs/writing-code-in-dbt/jinja-context/var 302 /docs/version /reference/global-cli-flags#version 302 -/docs/videos /docs/guides/videos 302 +/docs/videos /guides/legacy/videos 302 /docs/viewpoint /docs/about/viewpoint 302 /docs/windows /dbt-cli/installation 302 /docs/writing-code-in-dbt/class-reference /reference/dbt-classes 302 -/docs/writing-code-in-dbt/extending-dbts-programming-environment/creating-new-materializations /docs/guides/creating-new-materializations 302 -/docs/writing-code-in-dbt/extending-dbts-programming-environment/custom-schema-tests /docs/guides/writing-custom-schema-tests 302 +/docs/writing-code-in-dbt/extending-dbts-programming-environment/creating-new-materializations /guides/legacy/creating-new-materializations 302 +/docs/writing-code-in-dbt/extending-dbts-programming-environment/custom-schema-tests /guides/legacy/writing-custom-schema-tests 302 /docs/writing-code-in-dbt/getting-started-with-jinja /docs/building-a-dbt-project/jinja-macros 302 /docs/writing-code-in-dbt/jinja-context/adapter /reference/dbt-jinja-functions/adapter 302 /docs/writing-code-in-dbt/jinja-context/as_text /reference/dbt-jinja-functions/as_text 302 @@ -322,5 +331,4 @@ https://tutorial.getdbt.com/* https://docs.getdbt.com/:splat 301! /docs/guides/migration-guide/upgrading-to-v1.0 /guides/migration/versions/upgrading-to-v1.0 302 /docs/guides/getting-help /guides/legacy/getting-help 302 /docs/guides/migration-guide/* /guides/migration/versions/:splat 301! -/docs/guides/best-practices /guides/best-practices /docs/guides/* /guides/legacy/:splat 301! diff --git a/website/blog/2022-06-30-coalesce-sql.md b/website/blog/2022-06-30-coalesce-sql.md index 4abbbcdd8e6..8266cce30fd 100644 --- a/website/blog/2022-06-30-coalesce-sql.md +++ b/website/blog/2022-06-30-coalesce-sql.md @@ -7,8 +7,7 @@ authors: [kira_furuichi] tags: [SQL Magic] hide_table_of_contents: false - -date: 2022-06-30 +date: 2022-05-08 is_featured: false --- @@ -19,7 +18,6 @@ COALESCE is an incredibly useful function that allows you to fill in unhelpful b > **What is a SQL Function?** -> > At a high level, a function takes an input (or multiple inputs) and returns a manipulation of those inputs. Some common SQL functions are [EXTRACT](https://docs.getdbt.com/blog/extract-sql-love-letter/), [LOWER](https://docs.getdbt.com/blog/lower-sql-love-letter/), and [DATEDIFF](https://docs.getdbt.com/blog/datediff-sql-love-letter/). For example, the LOWER function takes a string value and returns an all lower-case version of that input string. ## How to use the COALESCE function @@ -34,7 +32,7 @@ coalesce(, ,...) You can have as many input values/columns to the COALESCE function as you like, but remember: order is important here since the first non-null value is the one that is returned. In practice, you’ll likely only ever use the COALESCE function with two inputs: a column and the value you want to fill null values of that column with. -> **Fun Fact** +> **See it in action:** > The COALESCE function is used in the [surrogate_key](https://docs.getdbt.com/blog/sql-surrogate-keys) macro to replace null column values. ### Data warehouse support for the COALESCE function @@ -60,7 +58,7 @@ select order_id, order_date, coalesce(order_status, 'not_returned') as order_status -from orders +from {{ ref('orders') }} ``` Running this query would return the following: @@ -73,7 +71,7 @@ Running this query would return the following: Now, there are no null values in the `order_status` column since any null value was replaced by a `not_returned` string. Order 34553’s `order_status` remained unchanged because its original `order_status` was the first non-null value passed in the COALESCE function. By providing more context into what these null values mean, anyone who looks at this table can quickly understand the order status for a specific order. -> **Important:** +> **To replace or not to replace:** > COALESCE has a straightforward use case—fill missing values with values you specify—but you also want to ensure you’re not changing non-empty values when using it. This is where the order of the input values to the COALESCE function are important: from left to right, the first non-null value is the one that’s returned. ## Why we love it diff --git a/website/blog/2022-06-30-extract-sql-function.md b/website/blog/2022-06-30-extract-sql-function.md index 6378da835b3..b81a7254a76 100644 --- a/website/blog/2022-06-30-extract-sql-function.md +++ b/website/blog/2022-06-30-extract-sql-function.md @@ -8,7 +8,7 @@ authors: [kira_furuichi] tags: [SQL Magic] hide_table_of_contents: false -date: 2022-06-30 +date: 2022-05-15 is_featured: false --- There are so many different date functions in SQL—you have [DATEDIFF](https://docs.getdbt.com/blog/datediff-sql-love-letter/), [DATEADD](https://docs.getdbt.com/blog/sql-dateadd), DATE_PART, and [DATE_TRUNC](https://docs.getdbt.com/date-trunc-sql) to name a few. They all have their different use cases and understanding how and when they should be used is a SQL fundamental to get down. Are any of those as easy to use as the EXTRACT function? Well, that debate is for another time… @@ -20,7 +20,7 @@ In this post, we’re going to give a deep dive into the EXTRACT function, how i The EXTRACT function allows you to extract a specified date part from a date/time. For example, if you were to extract the month from the date February 14, 2022, it would return 2 since February is the second month in the year. > **What is a SQL function?** -> At a high level, a function takes an input (or multiple inputs) and returns a manipulation of those inputs. Some common SQL functions are [COALESCE](https://docs.getdbt.com/blog/coalesce-sql-love-letter/), [LOWER],(https://docs.getdbt.com/blog/lower-sql-love-letter/) and [DATEDIFF](https://docs.getdbt.com/blog/datediff-sql-love-letter/). For example, the COALESCE function takes a group of values and returns the first non-null value from that group. +> At a high level, a function takes an input (or multiple inputs) and returns a manipulation of those inputs. Some common SQL functions are [COALESCE](https://docs.getdbt.com/blog/coalesce-sql-love-letter/), [LOWER](https://docs.getdbt.com/blog/lower-sql-love-letter/) and [DATEDIFF](https://docs.getdbt.com/blog/datediff-sql-love-letter/). For example, the COALESCE function takes a group of values and returns the first non-null value from that group. ## How to use the EXTRACT function diff --git a/website/blog/2022-06-30-lower-sql-function.md b/website/blog/2022-06-30-lower-sql-function.md index f1c3a811845..353b11376b0 100644 --- a/website/blog/2022-06-30-lower-sql-function.md +++ b/website/blog/2022-06-30-lower-sql-function.md @@ -8,13 +8,13 @@ authors: [kira_furuichi] tags: [SQL Magic] hide_table_of_contents: false -date: 2022-06-30 +date: 2022-05-11 is_featured: false --- We’ve all been there: -* In a user signup form, user A typed in their name as Kira Furuichi, user B typed it in as john blust, and user C wrote DAvid KrevitT (what’s up with that, David??) +* In a user signup form, user A typed in their name as `Kira Furuichi`, user B typed it in as `john blust`, and user C wrote `DAvid KrevitT` (what’s up with that, David??) * Your backend application engineers are adamant customer emails are in all caps * All of your event tracking names are lowercase @@ -73,7 +73,7 @@ After running this query, the `customers` table will look a little something lik Now, all characters in the `first_name` and `last_name` columns are lowercase. -> **Note:** +> **Where do you lower?** > Changing all string columns to lowercase to create uniformity across data sources typically happens in our dbt project’s [staging models](https://docs.getdbt.com/guides/best-practices/how-we-structure/2-staging). There are a few reasons for that: data cleanup and standardization, such as aliasing, casting, and lowercasing, should ideally happen in staging models to create downstream uniformity. It’s also more performant in downstream models that join on string values to join on strings that are of all the same casing versus having to join and perform lowercasing at the same time. ## Why we love it diff --git a/website/blog/2022-07-05-date-trunc-sql-love-letter.md b/website/blog/2022-07-05-date-trunc-sql-love-letter.md index 5f0791c68fc..61e5349d1ce 100644 --- a/website/blog/2022-07-05-date-trunc-sql-love-letter.md +++ b/website/blog/2022-07-05-date-trunc-sql-love-letter.md @@ -8,7 +8,7 @@ authors: [kira_furuichi] tags: [sql magic] hide_table_of_contents: true -date: 2022-07-05 +date: 2022-07-13 is_featured: false --- In general, data people prefer the more granular over the less granular. [Timestamps > dates](https://docs.getdbt.com/blog/when-backend-devs-spark-joy#signs-the-data-is-sparking-joy), daily data > weekly data, etc.; having data at a more granular level always allows you to zoom in. However, you’re likely looking at your data at a somewhat zoomed-out level—weekly, monthly, or even yearly. To do that, you’re going to need a handy dandy function that helps you round out date or time fields. @@ -20,10 +20,9 @@ Using the DATE_TRUNC function, you can truncate to the weeks, months, years, or > **What is a SQL function?** -> > At a high level, a function takes an input (or multiple inputs) and returns a manipulation of those inputs. Some common SQL functions are [COALESCE](https://getdbt.com/sql-foundations/coalesce-sql-love-letter/), [LOWER](https://getdbt.com/sql-foundations/lower-sql-love-letter/), and [EXTRACT](https://getdbt.com/sql-foundations/extract-sql-love-letter/). For example, the COALESCE function takes a group of values and returns the first non-null value from that group. -Overall, it’s a great function to use to help you aggregate your data into specific date parts while keeping a date format. However, the DATE_TRUNC function isn’t your swiss army knife–it’s not able to do magic or solve all of your problems (we’re looking at you [star](https://getdbt.com/sql-foundations/star-sql-love-letter/). Instead, DATE_TRUNC is your standard kitchen knife—it’s simple and efficient, and you almost never start cooking (data modeling) without it. +Overall, it’s a great function to use to help you aggregate your data into specific date parts while keeping a date format. However, the DATE_TRUNC function isn’t your swiss army knife–it’s not able to do magic or solve all of your problems (we’re looking at you [star](https://getdbt.com/sql-foundations/star-sql-love-letter/)). Instead, DATE_TRUNC is your standard kitchen knife—it’s simple and efficient, and you almost never start cooking (data modeling) without it. ## How to use the DATE_TRUNC function @@ -56,7 +55,7 @@ In [Google BigQuery](https://cloud.google.com/bigquery/docs/reference/standard-s date_trunc(, ) ``` -> **Note:** +> **A note on BigQuery:** > BigQuery’s DATE_TRUNC function supports the truncation of date types, whereas Snowflake, Redshift, and Databricks’ can be a date or timestamp data type. BigQuery also supports DATETIME_TRUNC and TIMESTAMP_TRUNC functions to support truncation of more granular date/time types. ## A dbt macro to remember diff --git a/website/blog/2022-07-05-datediff-sql-love-letter.md b/website/blog/2022-07-05-datediff-sql-love-letter.md new file mode 100644 index 00000000000..85a2dfe8afd --- /dev/null +++ b/website/blog/2022-07-05-datediff-sql-love-letter.md @@ -0,0 +1,93 @@ +--- +title: "DATEDIFF SQL function: Why we love it" +description: "The DATEDIFF function will return the difference in specified units (ex. days, weeks, years) between a start date/time and an end date/time. It’s a simple and widely used function that you’ll find yourself using more often than you expect." +slug: datediff-sql-love-letter + +authors: [kira_furuichi] + +tags: [sql magic] +hide_table_of_contents: false + +date: 2022-07-13 +is_featured: false +--- + +*“How long has it been since this customer last ordered with us?”* + +*“What is the average number of days to conversion?”* + +Business users will have these questions, data people will have to answer these questions, and the only way to solve them is by calculating the time between two different dates. Luckily, there’s a handy DATEDIFF function that can do that for you. + +The DATEDIFF function will return the difference in specified units (ex. days, weeks, years) between a start date/time and an end date/time. It’s a simple and widely used function that you’ll find yourself using more often than you expect. + + + +> **What is a SQL function?** +> At a high level, a function takes an input (or multiple inputs) and returns a manipulation of those inputs. Some common SQL functions are [COALESCE](https://getdbt.com/sql-foundations/coalesce-sql-love-letter/), [LOWER](https://getdbt.com/sql-foundations/lower-sql-love-letter/), and [EXTRACT](https://getdbt.com/sql-foundation/extract-sql-love-letter/). For example, the COALESCE function takes a group of values and returns the first non-null value from that group. + +DATEDIFF is a little bit like your favorite pair of socks; you’ll usually find the first one easily and feel like the day is going to be great. But for some reason, the matching sock requires a little digging in the drawer. DATEDIFF is this pair of socks—you’ll inevitably find yourself Googling the syntax almost every time you use it, but you can’t go through your day without using it. + +This post will go over how to use the DATEDIFF function across different data warehouses and how to write more standardized DATEDIFF functions using a dbt macro (or successfully find your socks as a pair in one go). + +## How to use the DATEDIFF function + +For the DATEDIFF function, there’s three elements, or arguments, passed in: + +* The date part: This is the days/months/weeks/years (unit) of the difference calculated +* The first (start) date/time +* The second (end) date/time + +The DATEDIFF function can be used in SELECT statements and WHERE clauses. + +Most, if not all, modern cloud data warehouses support some type of the DATEDIFF function. There may be some minor differences between the argument order and function name for DATEDIFF across data warehouses, but the functionality very much remains the same. + +Below, we’ll outline some of the slight differences in the implementation between some data warehouses. + +### DATEDIFF in Snowflake, Amazon Redshift, and Databricks + +The syntax for using the DATEDIFF function in [Snowflake](https://docs.snowflake.com/en/sql-reference/functions/datediff.html) and [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/r_DATEDIFF_function.html), and [Databricks](https://docs.databricks.com/sql/language-manual/functions/datediff3.html) looks like the following: + +```sql +datediff(, , ) +``` + +> **A note on Databricks:** +> Databricks additionally supports a separate [DATEDIFF function](https://docs.databricks.com/sql/language-manual/functions/datediff.html) that takes only two arguments: a start date and an end date. The function will always return the difference between two dates in days. + +### DATEDIFF in Google BigQuery + +The syntax for using the DATEDIFF function in [Google BigQuery](https://cloud.google.com/bigquery/docs/reference/standard-sql/datetime_functions#datetime_diff) looks like the following: + +Three minor differences in the implementation here: + +* Unlike in Snowflake, Amazon Redshift, and Databricks where the `` is passed as the first argument, the `` is passed in as the last argument in Google BigQuery. +* Google BigQuery also calls the function DATETIME_DIFF with an additional underscore separating the function name. This is on-par with [Google BigQuery’s preference to have underscores in function names](https://cloud.google.com/bigquery/docs/reference/standard-sql/date_functions). +* The DATETIME_DIFF arguments are datetimes, not dates; Snowflake, Redshift, and Databricks’ DATEDIFF functions support multiple date types such as dates and timestamps. BigQuery also supports a separate [DATE_DIFF function](https://cloud.google.com/bigquery/docs/reference/standard-sql/date_functions#date_diff) that will return the difference between two `date` types, unlike the DATETIME_DIFF that only supports the `datetime` type. + +## A hero in the shadows: The DATEDIFF dbt macro! + +You may be able to memorize the syntax for the DATEDIFF function for the primary data warehouse you use. What happens when you switch to a different one for a new job or a new data stack? Remembering if there’s an underscore in the function name or which argument the `` is passed in as is… no fun and leads to the inevitable, countless “datediff in bigquery” Google searches. + +Luckily, [dbt-core](https://github.com/dbt-labs/dbt-core) has your back! dbt Core is the open source dbt product that helps data folks write their data transformations following software engineering best practices. + +With dbt v1.2, [adapters](https://docs.getdbt.com/docs/available-adapters) now support [cross-database macros](https://docs.getdbt.com/reference/dbt-jinja-functions/cross-database-macros) to help you write certain functions, like [DATE_TRUNC](https://docs.getdbt.com/reference/dbt-jinja-functions/cross-database-macros#date_trunc) and [DATEDIFF](https://docs.getdbt.com/reference/dbt-jinja-functions/cross-database-macros#datediff), without having to memorize sticky function syntax. + +> **Note:** +> Previously, [dbt_utils](https://github.com/dbt-labs/dbt-utils), a package of macros and tests that data folks can use to help write more DRY code in their dbt project, powered cross-database macros. Now, cross-database macros are available **regardless if dbt utils is installed or not.** + +Using the [DATEDIFF macro](https://docs.getdbt.com/reference/dbt-jinja-functions/cross-database-macros#datediff), you can calculate the difference between two dates without having to worry about finicky syntax. Specifically, this means you could successfully run the *same code* across multiple databases without having to worry about the finicky differences in syntax. + +Using the [jaffle shop](https://github.com/dbt-labs/jaffle_shop/blob/main/models/orders.sql), a simple dataset and dbt project, we can calculate the difference between two dates using the dbt DATEDIFF macro: + +```sql +select + *, + {{ datediff("order_date", "'2022-06-09'", "day") }} +from {{ ref('orders') }} +``` + +This would return all fields from the `orders` table and the difference in days between order dates and June 9, 2022. + +Under the hood, this macro is taking your inputs and creating the appropriate SQL syntax for the DATEDIFF function *specific to your data warehouse.* + +*This post is a part of the SQL love letters—a series on the SQL functions the dbt Labs data team members use and love. You can find [the entire collection here](https://getdbt.com/sql-foundations/top-sql-functions).* diff --git a/website/blog/2022-07-13-star-sql-love-letter.md b/website/blog/2022-07-13-star-sql-love-letter.md new file mode 100644 index 00000000000..87469dc2730 --- /dev/null +++ b/website/blog/2022-07-13-star-sql-love-letter.md @@ -0,0 +1,83 @@ +--- +title: "A star (generator) is born" +description: "One of the macros dbt utils offers is the `star` generator. This dbt macro is one of our favorites because it lets you select all the fields you want without writing the columns you don't." +slug: star-sql-love-letter + +authors: [kira_furuichi] + +tags: [sql magic] +hide_table_of_contents: false + +date: 2022-05-23 +is_featured: true +--- + + +We’ve likely been here: Table A has 56 columns and we want to select all but one of them (`column_56`). So here we go, let’s get started… + +```sql +select + column_1, + column_2, + column_3, + please_save_me… +from {{ ref('table_a') }} +``` + +At this point, you realize your will to continue typing out the next 52 columns has essentially dwindled down to nothing and you’re probably questioning the life choices that led you here. + +But what if there was a way to make these 56+ lines of code come down to a handful? Well, that’s where a handy [dbt macro](https://docs.getdbt.com/docs/building-a-dbt-project/jinja-macros) comes into play. + + + +## The `star` dbt macro + +dbt supports [dbt_utils](https://github.com/dbt-labs/dbt-utils), a [package of macros and tests](https://docs.getdbt.com/docs/building-a-dbt-project/package-management) that data folks can use to help them write more code in their dbt project. One of the macros dbt utils offers is the `star` generator. + +This macro: + +* Generates a comma-separated list of all fields that exist in the `from` [relation](https://docs.getdbt.com/reference/dbt-classes#relation) and excludes any fields listed in an `except` argument, +* Can optionally add a prefix to all generated fields using the `relation_alias` argument, +* And also concatenate prefixes and/or suffixes to all generated fields using the `prefix` and `suffix` arguments + +So what does this mean for the example from above? Instead of writing out all 55 columns, you can use the `star` macro to select all fields except the column you don’t want: + +```sql +select + {{ dbt_utils.star(from=ref('table_a'), except=['column_56'] }} +from {{ ref('table_a') }} +``` + +This dbt model compiles to: + +```sql +select + column_1, + column_2, + …, --imagine we weren’t lazy and wrote out all other columns + column_55 +from table_a +``` + +With the `star` macro, all of the columns except `column_56` are generated in a comma-separated list within the `select` statement. What was once 56+ lines of tedious, mind-numbing SQL becomes 3 lines using the `star` macro. You can also exclude multiple columns by passing in the column names to the `except` argument. + +If you want to alias all fields in a model with the same alias without having to explicitly rename them all, you can also use the `star` macro with the `relation_alias` argument passed in: + +```sql +select + {{ dbt_utils.star(from=ref('table_a'), relation_alias='my_new_alias') }} +from {{ ref('table_a') }} +``` + +Now, this will return all fields from `table_a` with the `my_new_alias.field_name` naming format. + +[Under the hood](https://github.com/dbt-labs/dbt-utils/blob/main/macros/sql/star.sql), the `star` macro is actually using another dbt utils macro ([get_filtered_columns_in_relation](https://github.com/dbt-labs/dbt-utils#get_filtered_columns_in_relation-source)) to loop through fields to either select, alias, and/or append some string values to them. + +## Why we love the `star` macro + +It’s no hidden fact: the Data Team at dbt Labs loves to use dbt util’s macros and tests when appropriate. We like dbt utils so much we created a March Madness Utils Bracket for them (not taking questions at this time) and we used the `star` macro alone over 30 times in our internal dbt repository. + +![](/img/blog/2022-07-13-star-sql-love-letter/utils-madness-1.png) + + +Overall, the `star` macro is a great way to dip your toes into the dbt utils package, write DRY code, and reduce your carpal tunnel. \ No newline at end of file diff --git a/website/docs/docs/dbt-cloud/dbt-cloud-enterprise/setting-up-enterprise-sso-with-azure-active-directory.md b/website/docs/docs/dbt-cloud/dbt-cloud-enterprise/setting-up-enterprise-sso-with-azure-active-directory.md index cb5f0b29fa2..b84c51eedc2 100644 --- a/website/docs/docs/dbt-cloud/dbt-cloud-enterprise/setting-up-enterprise-sso-with-azure-active-directory.md +++ b/website/docs/docs/dbt-cloud/dbt-cloud-enterprise/setting-up-enterprise-sso-with-azure-active-directory.md @@ -42,11 +42,6 @@ need to select the appropriate directory and then register a new application. Redirect URI values for single-tenant and multi-tenant deployments. For most enterprise use-cases, you will want to use the single-tenant Redirect URI. -:::note VPC Deployment -If you are deploying dbt Cloud into a VPC, you should use the hostname where -the dbt Cloud application is deployed instead of `https://cloud.getdbt.com` in -the **Redirect URI** input. -::: | Application Type | Redirect URI | | ----- | ----- | @@ -139,13 +134,6 @@ Under **Properties** check the toggle setting for **User assignment required?** To complete setup, follow the steps below in the dbt Cloud application. -### Enable Azure AD Native Auth (beta) - -- For users accessing dbt Cloud at cloud.getdbt.com, contact your account manager to - gain access to the Azure AD Native auth configuration UI -- For users accessing dbt Cloud deployed in a VPC, enable the `native_azure` - feature flag in the dbt Cloud admin backend. - ### Supplying credentials 24. Navigate to the **Enterprise > Single Sign On** page under Account diff --git a/website/docs/guides/migration/versions/06-upgrading-to-v1.2.md b/website/docs/guides/migration/versions/06-upgrading-to-v1.2.md index e1375787765..f66c2402782 100644 --- a/website/docs/guides/migration/versions/06-upgrading-to-v1.2.md +++ b/website/docs/guides/migration/versions/06-upgrading-to-v1.2.md @@ -19,7 +19,7 @@ The manifest schema version has been updated to `v6`. The relevant changes are: - Change to `config` default, which includes a new `grants` property with default value `{}` - Addition of a `metrics` property, to any node which could reference metrics using the `metric()` function -For users of [state-based selection](understanding-state): This release also includes new logic declaring forwards compatibility for older manifest versions. While running dbt Coree v1.2, it should be possible to use `state:modified --state ...` selection against a manifest produced by dbt Core v1.0 or v1.1. +For users of [state-based selection](understanding-state): This release also includes new logic declaring forwards compatibility for older manifest versions. While running dbt Core v1.2, it should be possible to use `state:modified --state ...` selection against a manifest produced by dbt Core v1.0 or v1.1. ## For maintainers of adapter plugins @@ -28,7 +28,7 @@ See GitHub discussion [dbt-labs/dbt-core#5468](https://github.com/dbt-labs/dbt-c ## New and changed documentation - **[Grants](/reference/resource-configs/grants)** are natively supported in `dbt-core` for the first time. That support extends to all standard materializations, and the most popular adapters. If you already use hooks to apply simple grants, we encourage you to use built-in `grants` to configure your models, seeds, and snapshots instead. This will enable you to [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) up your duplicated or boilerplate code. -- **[dbt-Jinja functions](reference/dbt-jinja-functions)** now include the [`itertools` Python module](dbt-jinja-functions/modules#itertools), as well as the [set](dbt-jinja-functions/set) and [zip](dbt-jinja-functions/zip) functions. +- **[dbt-Jinja functions](/reference/dbt-jinja-functions)** now include the [`itertools` Python module](dbt-jinja-functions/modules#itertools), as well as the [set](dbt-jinja-functions/set) and [zip](dbt-jinja-functions/zip) functions. - **[Node selection](node-selection/syntax)** includes a [file selection method](node-selection/methods#the-file-method) (`-s model.sql`), and [yaml selector](node-selection/yaml-selectors) inheritance. - **[Global configs](global-configs)** now include CLI flag and environment variable settings for [`target-path`](target-path) and [`log-path`](log-path), which can be used to override the values set in `dbt_project.yml` - **[Metrics](building-a-dbt-project/metrics)** now support an `expression` type (metrics-on-metrics), as well as a `metric()` function to use when referencing metrics from within models, macros, or `expression`-type metrics. For more information how to use expression metrics, please reference the [**`dbt_metrics` package**](https://github.com/dbt-labs/dbt_metrics) diff --git a/website/docs/reference/resource-properties/tests.md b/website/docs/reference/resource-properties/tests.md index 713db0c56cc..a77e18c096c 100644 --- a/website/docs/reference/resource-properties/tests.md +++ b/website/docs/reference/resource-properties/tests.md @@ -436,7 +436,7 @@ $ dbt test ### Alternative format for defining tests -When defining a generic test with a number of arguments and configurations, the YAML can look and feel unwieldy. If you find it easier easier, you can define the same test properties as top-level keys of a single dictionary, by providing the test name as `test_name` instead. It's totally up to you. +When defining a generic test with a number of arguments and configurations, the YAML can look and feel unwieldy. If you find it easier, you can define the same test properties as top-level keys of a single dictionary, by providing the test name as `test_name` instead. It's totally up to you. This example is identical to the one above: diff --git a/website/static/img/blog/2022-07-13-star-sql-love-letter/star-is-born.jpg b/website/static/img/blog/2022-07-13-star-sql-love-letter/star-is-born.jpg new file mode 100644 index 00000000000..53192f53206 Binary files /dev/null and b/website/static/img/blog/2022-07-13-star-sql-love-letter/star-is-born.jpg differ diff --git a/website/static/img/blog/2022-07-13-star-sql-love-letter/utils-madness-1.png b/website/static/img/blog/2022-07-13-star-sql-love-letter/utils-madness-1.png new file mode 100644 index 00000000000..faf078cd2bc Binary files /dev/null and b/website/static/img/blog/2022-07-13-star-sql-love-letter/utils-madness-1.png differ diff --git a/website/static/img/blog/2022-07-13-star-sql-love-letter/utils-madness-2.png b/website/static/img/blog/2022-07-13-star-sql-love-letter/utils-madness-2.png new file mode 100644 index 00000000000..94b99f28a8c Binary files /dev/null and b/website/static/img/blog/2022-07-13-star-sql-love-letter/utils-madness-2.png differ