From bd73e21d9e8d7528a8e0ca88ee390d426526b37c Mon Sep 17 00:00:00 2001 From: Jeremy Cohen Date: Fri, 4 Oct 2024 18:15:04 -0400 Subject: [PATCH] Fix bad ref in microbatch docs (#6249) Thanks to @matt-winkler for spotting this one (and props for carefully reading the docs on an exciting new feature while it's in beta) --- website/docs/docs/build/incremental-microbatch.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/build/incremental-microbatch.md b/website/docs/docs/build/incremental-microbatch.md index ae598bbe05f..b4b5406127e 100644 --- a/website/docs/docs/build/incremental-microbatch.md +++ b/website/docs/docs/build/incremental-microbatch.md @@ -28,7 +28,7 @@ A `sessions` model is aggregating and enriching data that comes from two other m - `page_views` is a large, time-series table. It contains many rows, new records almost always arrive after existing ones, and existing records rarely update. - `customers` is a relatively small dimensional table. Customer attributes update often, and not in a time-based manner — that is, older customers are just as likely to change column values as newer customers. -The `page_view_start` column in `page_views` is configured as that model's `event_time`. The `customers` model does not configure an `event_time`. Therefore, each batch of `sessions` will filter `page_views` to the equivalent time-bounded batch, and it will not filter `sessions` (a full scan for every batch). +The `page_view_start` column in `page_views` is configured as that model's `event_time`. The `customers` model does not configure an `event_time`. Therefore, each batch of `sessions` will filter `page_views` to the equivalent time-bounded batch, and it will not filter `customers` (a full scan for every batch). We run the `sessions` model on October 1, 2024, and then again on October 2. It produces the following queries: