Skip to content

feat: store %%sparksql results in _df by default - #203

Merged
dborowitz merged 1 commit into
GoogleCloudDataproc:mainfrom
dborowitz:under-df
Oct 16, 2026
Merged

dborowitz merged 1 commit into
GoogleCloudDataproc:mainfrom
dborowitz:under-df

Conversation

@dborowitz

Copy link
Copy Markdown
Contributor

When a %%sparksql cell does not name a target variable, store the resulting un-truncated DataFrame in _df in the notebook namespace. Passing an explicit variable name stores the result there instead of _df, and the %sparksql line magic still returns the DataFrame directly without modifying the namespace. As before, the variable is only bound once execution and display succeed.

When a %%sparksql cell does not name a target variable, store the resulting
un-truncated DataFrame in `_df` in the notebook namespace. Passing an explicit
variable name stores the result there instead of `_df`, and the `%sparksql`
line magic still returns the DataFrame directly without modifying the
namespace. As before, the variable is only bound once execution and display
succeed.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the %%sparksql magic command to store the resulting DataFrame in a default variable named _df when no explicit variable name is provided in cell form. The documentation, implementation, and corresponding unit and local tests have been updated to reflect and verify this new default behavior. There are no review comments to address, and the changes look solid.

@dborowitz
dborowitz merged commit 1aced7f into GoogleCloudDataproc:main Oct 16, 2026
11 checks passed
@dborowitz
dborowitz deleted the under-df branch October 16, 2026 01:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants