Merge branch 'current' into dbeatty/remove-period-from-title

website/blog/2023-05-02-modeling-ragged-time-varying-hierarchies.md

@@ -16,6 +16,8 @@ This article covers an approach to handling time-varying ragged hierarchies in a
 
 To help visualize this data, we're going to pretend we are a company that manufactures and rents out eBikes in a ride share application.  When we build a bike, we keep track of the serial numbers of the components that make up the bike.  Any time something breaks and needs to be replaced, we track the old parts that were removed and the new parts that were installed.  We also precisely track the mileage accumulated on each of our bikes.  Our primary analytical goal is to be able to report on the expected lifetime of each component, so we can prioritize improving that component and reduce costly maintenance.
 
+<!--truncate-->
+
 ## Data model
 
 Obviously, a real bike could have a hundred or more separate components.  To keep things simple for this article, let's just consider the bike, the frame, a wheel, the wheel rim, tire, and tube.  Our component hierarchy looks like:

website/blog/2023-10-31-to-defer-or-to-clone.md

@@ -87,7 +87,7 @@ Using the cheat sheet above, let’s explore a few common scenarios and explore
     1. Make a copy of our production dataset available in our downstream BI tool
     2. To safely iterate on this copy without breaking production datasets
 
-    Therefore, we should use **clone** in this scenario
+    Therefore, we should use **clone** in this scenario.
 
 2. **[Slim CI](https://discourse.getdbt.com/t/how-we-sped-up-our-ci-runs-by-10x-using-slim-ci/2603)**
 
@@ -96,7 +96,11 @@ Using the cheat sheet above, let’s explore a few common scenarios and explore
     2. Only run and test models in the CI staging environment that have changed from the production environment
     3. Reference models from different environments – prod for unchanged models, and staging for modified models
 
-    Therefore, we should use **defer** in this scenario
+    Therefore, we should use **defer** in this scenario.
+
+:::tip Use `dbt clone` in CI jobs to test incremental models
+Learn how to [use `dbt clone` in CI jobs](/best-practices/clone-incremental-models) to efficiently test modified incremental models, simulating post-merge behavior while avoiding full-refresh costs.
+:::
 
 3. **[Blue/Green Deployments](https://discourse.getdbt.com/t/performing-a-blue-green-deploy-of-your-dbt-project-on-snowflake/1349)**
 

website/docs/reference/configs-and-properties.md

@@ -3,7 +3,7 @@ title: Configs, properties, what are they?
 ---
 
 Resources in your project—models, snapshots, seeds, tests, and the rest—can have a number of declared **properties**. Resources can also define **configurations**, which are a special kind of property that bring extra abilities. What's the distinction?
-- Properties are declared for resources one-by-one in `.yml` files. Configs can be defined there, nested under a `config` property. They can also be set one-by-one via a `config()` macro (right within `.sql` files), and for many resources at once in `dbt_project.yml`.
+- Properties are declared for resources one-by-one in  `properties.yml` files. Configs can be defined there, nested under a `config` property. They can also be set one-by-one via a `config()` macro (right within `.sql` files), and for many resources at once in `dbt_project.yml`.
 - Because configs can be set in multiple places, they are also applied hierarchically. An individual resource might _inherit_ or _override_ configs set elsewhere.
 - You can select resources based on their config values using the `config:` selection method, but not the values of non-config properties
 
@@ -46,9 +46,7 @@ Most configurations are "clobbered" when applied hierarchically. Whenever a more
 
 ## Where can I define properties?
 
-In dbt, properties are declared in `.yml` files, in the same directory as your resources.
-
-You can name these files `whatever_you_want.yml` and nest them arbitrarily deeply in subfolders within each directory.
+In dbt, you can use `properties.yml` files to define properties for resources. You can declare properties in `.yml` files, in the same directory as your resources. You can name these files `whatever_you_want.yml` and nest them arbitrarily in sub-folders within each directory. 
 
 We highly recommend that you define properties in dedicated paths alongside the resources they're describing.
 
@@ -58,13 +56,13 @@ We highly recommend that you define properties in dedicated paths alongside the
 
 Previous versions of the docs referred to these as `schema.yml` files — we've moved away from that terminology since the word `schema` is used to mean other things when talking about databases, and people often thought that you _had_ to name these files `schema.yml`.
 
-(Of course, you're still free to name your files `schema.yml`)
+Instead, we now refer to these files as `properties.yml` files. (Of course, you're still free to name your files `schema.yml`)
 
 :::
 
 ### Which properties are _not_ also configs?
 
-dbt has the ability to define node configs in `.yml` files, in addition to `config()` blocks and `dbt_project.yml`. But the reverse isn't always true: there are some things in `.yml` files that can _only_ be defined there.
+In dbt, you can define node configs in `properties.yml` files, in addition to `config()` blocks and `dbt_project.yml`. However, some special properties can only be defined in the `.yml` file and you cannot configure them using `config()` blocks or the `dbt_project.yml` file:
 
 Certain properties are special, because:
 

website/docs/reference/dbt_project.yml.md

@@ -15,13 +15,15 @@ Starting from dbt v1.5 and higher, you can specify your dbt Cloud project ID in
 
 </VersionBlock>
 
-The following is a list of all available configurations in the `dbt_project.yml` file.
-
 :::info YAML syntax
-dbt uses YAML in a few different places. If you're new to YAML, it would be worth taking the time to learn how arrays, dictionaries and strings are represented.
+dbt uses YAML in a few different places. If you're new to YAML, it would be worth taking the time to learn how arrays, dictionaries, and strings are represented.
 :::
 
 
+Something to note, you can't set up a "property" in the `dbt_project.yml` file if it's not a config (an example is [macros](/reference/macro-properties)). This applies to all types of resources. Refer to [Configs and properties](/reference/configs-and-properties) for more detail.
+
+The following example is a list of all available configurations in the `dbt_project.yml` file:
+
 <VersionBlock firstVersion="1.7">
 
 <File name='dbt_project.yml'>

website/snippets/_sl-faqs.md

@@ -44,7 +44,7 @@ If you're using the legacy Semantic Layer, we highly recommend you [upgrade your
 
 </detailsToggle>
 
-<detailsToggle alt_header="How are you storing my data?*">
+<detailsToggle alt_header="How are you storing my data?">
 
 User data passes through the Semantic Layer on its way back from the warehouse. dbt Labs ensures security by authenticating through the customer's data warehouse. Currently, we don't cache data for the long term, but it might temporarily stay in the system for up to 10 minutes, usually less. In the future, we'll introduce a caching feature that allows us to cache data on our infrastructure for up to 24 hours.
 

website/src/components/detailsToggle/index.js

@@ -7,29 +7,29 @@ function detailsToggle({ children, alt_header = null }) {
   const [hoverTimeout, setHoverTimeout] = useState(null);
 
   const handleToggleClick = () => {
-    setOn(false);
-    setHoverActive(isOn); // Toggle hover activation based on current state
-  };
+    setHoverActive(true); // Disable hover when clicked
+    setOn(current => !current); // Toggle the current state
+};
 
-  const handleMouseEnter = () => {
-    if (!hoverActive) return; // Ignore hover if disabled
-    const timeout = setTimeout(() => {
-      setOn(true);
-    }, 500); // 500ms delay
-    setHoverTimeout(timeout);
-  };
+const handleMouseEnter = () => {
+  if (isOn) return; // Ignore hover if already open
+  setHoverActive(true); // Enable hover
+  const timeout = setTimeout(() => {
+      if (hoverActive) setOn(true);
+  }, 500); 
+  setHoverTimeout(timeout);
+};
 
-  const handleMouseLeave = () => {
-    if (hoverActive && !isOn) {
+const handleMouseLeave = () => {
+  if (!isOn) {
       clearTimeout(hoverTimeout);
       setOn(false);
-      // isOn (false); can't be used here but setOn triggers a re-render
-    }
-  };
+  }
+};
 
-  useEffect(() => {
-    return () => clearTimeout(hoverTimeout);
-  }, [hoverTimeout]);
+useEffect(() => {
+  return () => clearTimeout(hoverTimeout);
+}, [hoverTimeout]);
 
   return (
     <div className='detailsToggle'>