Skip to content

[SPARK-56619][CONNECT][TESTS] Add DSv2 repeated table access tests with internal/external changes in Spark Connect-clone#55573

Closed
longvu-db wants to merge 2 commits intoapache:masterfrom
longvu-db:dsv2-connect-pr2-repeated-sql-clone
Closed

[SPARK-56619][CONNECT][TESTS] Add DSv2 repeated table access tests with internal/external changes in Spark Connect-clone#55573
longvu-db wants to merge 2 commits intoapache:masterfrom
longvu-db:dsv2-connect-pr2-repeated-sql-clone

Conversation

@longvu-db
Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

Add 6 tests in a new DataSourceV2RepeatedSQLConnectSuite that verify DSv2 tables reflect the latest state when accessed repeatedly via sql() in Spark Connect mode (without CACHE TABLE). Each sql("SELECT * FROM t") call creates a fresh plan that is re-analyzed on the server, so it always sees the most recent data, schema, and table identity.

The tests use an in-process Connect server (SparkConnectServerTest) and cover three scenarios, each with a session-write and an external-write variant:

  • Scenario 1 (external writes): After a writer adds rows (via session SQL or catalog API), a subsequent sql() query sees the new data.
  • Scenario 2 (external schema changes): After a writer adds a column and inserts data with the new schema (via session SQL or catalog API), a subsequent sql() query reflects the updated schema.
  • Scenario 3 (drop/recreate): After a writer drops and recreates the table (via session SQL or catalog API), a subsequent sql() query sees the empty recreated table.

External writes use getServerSession() to access the server-side catalog API (loadTable with write privileges, alterTable, dropTable/createTable), matching the pattern used by the classic-mode tests in #55462.

Why are the changes needed?

These tests document and lock down the expected behavior: repeated sql() access in Connect mode always sees the latest table state. This prevents regressions if internal resolution or caching logic changes. This is the Connect companion to the classic-mode tests in #55462.

Does this PR introduce any user-facing change?

No. This PR is test-only.

How was this patch tested?

6 new tests in DataSourceV2RepeatedSQLConnectSuite, all passing:

build/sbt 'connect/testOnly *DataSourceV2RepeatedSQLConnectSuite'

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code (claude-opus-4-6)

Adds 6 tests to verify that repeated sql() calls in Spark Connect
mode always see the latest table state. This mirrors the classic-mode
tests added to DataSourceV2DataFrameSuite, covering:

1. Session write: INSERT via SQL, next SELECT sees new row
2. External write: data added via catalog API, next SELECT sees it
3. Session schema change: ADD COLUMN via SQL, next SELECT sees new schema
4. External schema change: column added via catalog API, next SELECT sees it
5. Session drop/recreate: DROP+CREATE via SQL, next SELECT sees empty table
6. External drop/recreate: drop+create via catalog API, next SELECT sees empty

In Connect, every sql() call creates a fresh plan re-analyzed on the
server, so all modifications are always visible.

Co-authored-by: Isaac
Co-authored-by: Isaac
@longvu-db longvu-db closed this Apr 27, 2026
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.

1 participant