SNOW-3489991: Block flattening of dropped NEW columns in connect mode#4259
Draft
sfc-gh-joshi wants to merge 2 commits into
Draft
SNOW-3489991: Block flattening of dropped NEW columns in connect mode#4259sfc-gh-joshi wants to merge 2 commits into
sfc-gh-joshi wants to merge 2 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4259 +/- ##
=======================================
Coverage 95.49% 95.49%
=======================================
Files 171 171
Lines 44243 44244 +1
Branches 7548 7548
=======================================
+ Hits 42252 42253 +1
Misses 1226 1226
Partials 765 765 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
In can_select_statement_be_flattened, the existing guard only refused to flatten when a dropped NEW column was also is_referenced_by_same_level_column. This missed the case where a future filter/sort (not yet added at select() time) references the dropped column, generating invalid SQL. In connect mode, extend the guard to block flattening unconditionally when a NEW column is dropped. This preserves the defining subquery and keeps the column visible to subsequent WHERE/ORDER BY clauses. Non-connect behavior is unchanged. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…tement flag Instead of checking `context._is_snowpark_connect_compatible_mode` broadly in `can_select_statement_be_flattened` (which blocked flattening for *all* dropped-NEW column cases in connect mode), introduce a `protect_dropped_new_columns` bool on `SelectStatement`. SCOS sets this flag specifically on the select statement produced by the withColumn path; `can_select_statement_be_flattened` honours it only for that statement. Non-withColumn paths (e.g. `select().order_by().select()`) are unaffected and continue to flatten normally, keeping generated SQL concise. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
25dd36a to
b1a9a74
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In can_select_statement_be_flattened, the existing guard only refused to flatten when a dropped NEW column was also is_referenced_by_same_level_column. This missed the case where a future filter/sort (not yet added at select() time) references the dropped column, generating invalid SQL.
In connect mode, extend the guard to block flattening unconditionally when a NEW column is dropped. This preserves the defining subquery and keeps the column visible to subsequent WHERE/ORDER BY clauses. Non-connect behavior is unchanged.
Which Jira issue is this PR addressing? Make sure that there is an accompanying issue to your PR.
Fixes SNOW-3489991
Fill out the following pre-review checklist:
Please describe how your code solves the related issue.
Please write a short description of how your code change solves the related issue.