feature: add optimize() call to snapshot materialization (#1335)#1341
feature: add optimize() call to snapshot materialization (#1335)#1341sd-db merged 3 commits intodatabricks:mainfrom
Conversation
Signed-off-by: aarushisingh04 <aarushi07.singh@gmail.com>
|
Overall the change looks good, one think I would look to add is: This inherits the full snapshot lifecycle test and confirms the behavior is preserved with optimize running |
Signed-off-by: aarushisingh04 <aarushi07.singh@gmail.com>
|
@sd-db agreed, added the required functional test in |
…stering test Signed-off-by: aarushisingh04 <aarushi07.singh@gmail.com>
sd-db
left a comment
There was a problem hiding this comment.
looks good, thx for the PR !!
## Summary - Followup to #1341; I realised the table v2 materialization path in `table.sql` was missing the `optimize()` call that exists in all other materialization paths (table v1, incremental v1, incremental v2) - When `use_materialization_v2` was enabled with `liquid_clustered_by`, `zorder`, or `auto_liquid_cluster` configured, `OPTIMIZE` would not run after table creation/replacement - Adds a functional test for table v2 + liquid clustering ## Test plan - [x] Unit tests pass (717/717) - [x] Functional test `TestTableV2LiquidClustering` passes — confirms `OPTIMIZE` runs in the v2 path - [x] Existing liquid clustering tests still pass (no regressions) Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
partially resolves #1335
Description
added
optimize()call to the snapshot materialization, matching existing behavior in table and incremental materializations. when a snapshot is configured withliquid_clustered_by,zorder, orauto_liquid_cluster, theOPTIMIZEquery will now execute automatically after each snapshot run.the change is a single-line addition to
snapshot.sql, placed afterpersist_constraintsand beforepost-hooks(again, consistent with the pattern intable.sqlandincremental.sql).note: the original issue also mentioned default clustering columns and
ALTER TABLEsupport for config changes. these are intentionally excluded from this PR to keep scope minimal and can be addressed in follow-up PRs if needed. i believe they need a design decision that should be discussed by/with maintainers first due to having a larger scope.Checklist
table.sqlandincremental.sql.)CHANGELOG.mdand added information about my change to the "dbt-databricks next" section.