Merge branch 'current' into jeremyyeo-patch-1

website/docs/docs/dbt-versions/release-notes/08-May-2023/may-ide-updates.md

@@ -1,46 +1,46 @@
----
-title: "May IDE updates and fixes"
-id: "may-ide-updates"
-description: "May 2023 release note: We've launched SQLFluff in beta, released an IDE UI page, significantly improved IDE performance, improved error messages, fixed bugs, and more."
-sidebar_label: "Update and fixes: IDE"
-sidebar_position: 2
-tags: [May-2023, IDE]
----
-
-To continue improving your [Cloud IDE](/docs/cloud/dbt-cloud-ide/develop-in-the-cloud) development experience, the dbt Labs team continues to work on adding new features, fixing bugs, and increasing reliability ✨.
-
-Stay up-to-date with [IDE-related changes](/tags/ide).
-
-## New features 
-- Lint via SQL Fluff is now available in beta (GA over the next 2-3 weeks)
-- Format markdown files with prettier
-- Leverage developer experience shortcuts, including ``Ctrl + ` `` (toggle history drawer), `CMD + Option + /` (toggle block comment), `CMD + Shift + P` (open command palette), `Option + W` (close editor tab)
-- Display parent folder name for files with same name in Changes section
-- Navigate the new IDE features quickly using [the IDE User Interface](/docs/cloud/dbt-cloud-ide/ide-user-interface) help page
-- Use `top X` in SQL when previewing in the IDE
-- Opt into the new IDE backend layer over the past month (still with dbt-rpc). Ready for beta later in June!
-
-
-## Product refinements 
-
-- Performance-related upgrades:
-    - Reduced cold start time by 60+%
-    - Improved render time of modals in the IDE by 98%
-    - Improved IDE performance with dbt Core v1.5+ (faster and snappier – highly encourage you to [upgrade your dbt version](/docs/dbt-versions/upgrade-core-in-cloud)!)
-- Upgraded sqlfmt (which powers the Format button) to 0.18.0
-- Updated Build button to change menu options based on file/model type (snapshot, macro, etc.)
-- Display message to disable adblocker for file contents error
-- Moved Format button to console bar
-- Made many security enhancements in the IDE
-## Bug fixes
-
-- File icon sizes no longer get wonky in small screen
-- Toast notifications no longer take over command bar menu
-- Hover info inside the text editor no longer gets cut off
-- Transition between a file and a recently modified scratchpad no longer triggers a console error
-- dbt v1.5+ now can access the IDE
-- Confirm button on the Unsaved Changes modal now closes after clicking it
-- Long node names no longer overflow in the parsed logs section in history drawer
-- Status pill in history drawer no longer scales with longer command
-- Tooltip for tab name with a long file name is no longer cut off
-- Lint button should no longer available in main branch
+---
+title: "May IDE updates and fixes"
+id: "may-ide-updates"
+description: "May 2023 release note: We've launched SQLFluff in beta, released an IDE UI page, significantly improved IDE performance, improved error messages, fixed bugs, and more."
+sidebar_label: "Update and fixes: IDE"
+sidebar_position: 2
+tags: [May-2023, IDE]
+---
+
+To continue improving your [Cloud IDE](/docs/cloud/dbt-cloud-ide/develop-in-the-cloud) development experience, the dbt Labs team continues to work on adding new features, fixing bugs, and increasing reliability ✨.
+
+Stay up-to-date with [IDE-related changes](/tags/ide).
+
+## New features 
+- Lint via SQL Fluff is now available in beta (GA over the next 2-3 weeks)
+- Format markdown files with prettier
+- Leverage developer experience shortcuts, including ``Ctrl + ` `` (toggle history drawer), `CMD + Option + /` (toggle block comment), `CMD + Shift + P` (open command palette), `Option + W` (close editor tab)
+- Display parent folder name for files with same name in Changes section
+- Navigate the new IDE features quickly using [the IDE User Interface](/docs/cloud/dbt-cloud-ide/ide-user-interface) help page
+- Use `top X` in SQL when previewing in the IDE
+- Opt into the new IDE backend layer over the past month (still with dbt-rpc). Ready for beta later in June!
+
+
+## Product refinements 
+
+- Performance-related upgrades:
+    - Reduced cold start time by 60+%
+    - Improved render time of modals in the IDE by 98%
+    - Improved IDE performance with dbt Core v1.5+ (faster and snappier – highly encourage you to [upgrade your dbt version](/docs/dbt-versions/upgrade-core-in-cloud)!)
+- Upgraded sqlfmt (which powers the Format button) to 0.18.0
+- Updated Build button to change menu options based on file/model type (snapshot, macro, etc.)
+- Display message to disable adblocker for file contents error
+- Moved Format button to console bar
+- Made many security enhancements in the IDE
+## Bug fixes
+
+- File icon sizes no longer get wonky in small screen
+- Toast notifications no longer take over command bar menu
+- Hover info inside the text editor no longer gets cut off
+- Transition between a file and a recently modified scratchpad no longer triggers a console error
+- dbt v1.5+ now can access the IDE
+- Confirm button on the Unsaved Changes modal now closes after clicking it
+- Long node names no longer overflow in the parsed logs section in history drawer
+- Status pill in history drawer no longer scales with longer command
+- Tooltip for tab name with a long file name is no longer cut off
+- Lint button should no longer available in main branch

website/docs/guides/dbt-ecosystem/sl-partner-integration-guide.md

@@ -50,7 +50,7 @@ When working with more governed data, it's essential to establish clear guardrai
 
 - **Aggregations control** — Users shouldn't generally be allowed to modify aggregations unless they perform post-processing calculations on Semantic Layer data (such as year-over-year analysis).
 
-- **Time series alignment and using metric_time** &mdash; Make sure users view metrics across the correct time series. When displaying metric graphs, using a non-default time aggregation dimension might lead to misleading interpretations. While users can still group by other time dimensions, they should be careful not to create trend lines with incorrect time axes.<br /><br />When looking at one or multiple metrics, users should use `metric_time` as the main time dimension to guarantee they are looking at the right time series for the metric(s). <br /><br /> As such, when building an application, we recommend exposing `metric_time` as a separate, "special" time dimension on its own. This dimension is always going to align with all metrics and be common across them. Other time dimensions can still be looked at and grouped by, but having a clear delineation between the `metric_time` dimension and the other time dimensions is clarifying so that people do not confuse how metrics should be plotted. <br /><br /> Also, when a user requests a time granularity change for the main time series, the query that your application runs should use `metric_time` as this will always give you the correct slice. Note that when looking at a single metric, the primary time dimension and `metric_time` are equivalent. 
+- **Time series alignment and using metric_time** &mdash; Make sure users view metrics across the correct time series. When displaying metric graphs, using a non-default time aggregation dimension might lead to misleading interpretations. While users can still group by other time dimensions, they should be careful not to create trend lines with incorrect time axes.<br /><br />When looking at one or multiple metrics, users should use `metric_time` as the main time dimension to guarantee they are looking at the right time series for the metric(s). <br /><br /> As such, when building an application, we recommend exposing `metric_time` as a separate, "special" time dimension on its own. This dimension is always going to align with all metrics and be common across them. Other time dimensions can still be looked at and grouped by, but having a clear delineation between the `metric_time` dimension and the other time dimensions is clarifying so that people do not confuse how metrics should be plotted. <br /><br /> Also, when a user requests a time granularity change for the main time series, the query that your application runs should use `metric_time` as this will always give you the correct slice. Related to this, we also strongly recommend that you have a way to expose what dimension `metric_time` actually maps to for users who may not be familiar. Our APIs allow you to fetch the actual underlying time dimensions that makeup metric_time (such as `transaction_date`) so you can expose them to your users.
 
 - **Units consistency** &mdash; If units are supported, it's vital to avoid plotting data incorrectly with different units. Ensuring consistency in unit representation will prevent confusion and misinterpretation of the data.
 
@@ -90,7 +90,7 @@ Allow users to query either one metric alone without dimensions or multiple metr
 - Only expose time granularities (monthly, daily, yearly) that match the available metrics. 
   * For example, if a dbt model and its resulting semantic model have a monthly granularity, make sure querying data with a 'daily' granularity isn't available to the user. Our APIs have functionality that will help you surface the correct granularities
 
-- We recommend that time granularity is treated as a general time dimension-specific concept and that it can be applied to more than just the primary aggregation (or `metric_time`). Consider a situation where a user wants to look at `sales` over time by `customer signup month`; in this situation, having the ability to apply granularities to both time dimensions is crucial. Note: Initially, as a starting point, it makes sense to only support `metric_time` or the primary time dimension, but we recommend expanding that as your solution evolves. 
+- We recommend that time granularity is treated as a general time dimension-specific concept and that it can be applied to more than just the primary aggregation (or `metric_time`). Consider a situation where a user wants to look at `sales` over time by `customer signup month`; in this situation, having the ability to apply granularities to both time dimensions is crucial. Our APIs include information to fetch the granularities for the primary (metric_time) dimensions, as well as all time dimensions. You can treat each time dimension and granularity selection independently in your application. Note: Initially, as a starting point, it makes sense to only support `metric_time` or the primary time dimension, but we recommend expanding that as your solution evolves. 
 
 - You should allow users to filter on date ranges and expose a calendar and nice presets for filtering these. 
   * For example, last 30 days, last week, and so on.

website/docs/reference/resource-configs/redshift-configs.md

@@ -15,22 +15,27 @@ To-do:
 In dbt-redshift, the following incremental materialization strategies are supported:
 
 <VersionBlock lastVersion="1.5">
+
 - `append` (default)
 - `delete+insert`
+
 </VersionBlock>
+
 <VersionBlock firstVersion="1.6">
+
 - `append` (default)
 - `merge`
 - `delete+insert`
+
 </VersionBlock>
 
-All of these strategies are inheirited via from dbt-postgres.
+All of these strategies are inherited from dbt-postgres.
 
 ## Performance optimizations
 
 ### Using sortkey and distkey
 
-Tables in Amazon Redshift have two powerful optimizations to improve query performance: distkeys and sortkeys. Supplying these values as model-level configurations apply the corresponding settings in the generated `CREATE TABLE` <Term id="ddl" />. Note that these settings will have no effect for models set to `view` or `ephemeral` models.
+Tables in Amazon Redshift have two powerful optimizations to improve query performance: distkeys and sortkeys. Supplying these values as model-level configurations apply the corresponding settings in the generated `CREATE TABLE` <Term id="ddl" />. Note that these settings will have no effect on models set to `view` or `ephemeral` models.
 
 - `dist` can have a setting of `all`, `even`, `auto`, or the name of a key.
 - `sort` accepts a list of sort keys, for example: `['timestamp', 'userid']`. dbt will build the sort key in the same order the fields are supplied.

website/snippets/cloud-feature-parity.md

@@ -10,5 +10,5 @@ The following table outlines which dbt Cloud features are supported on the diffe
 | Continuous Integration, including CI jobs                       | ✅           | ✅                     | ✅                   | 
 | Semantic Layer                | ✅ (North America Only) | ❌          | ❌                   | 
 | IP Restrictions               | ✅           | ✅                     | ✅                   | 
-| PrivateLink egress            | ✅           | ✅                     | ✅                   | 
+| PrivateLink egress            | ✅ (AWS only)| ✅                     | ✅                   | 
 | PrivateLink ingress           | ❌           | ✅                     | ✅                   |