[SPARK-56619][CONNECT][TESTS] Add DSv2 repeated table access tests with internal/external changes in Spark Connect#55456
Open
longvu-db wants to merge 12 commits intoapache:masterfrom
Open
Conversation
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
longvu-db
force-pushed
the
dsv2-connect-pr2-repeated-sql
branch
from
e0758b8 to
f94c5cf
Compare
longvu-db
changed the title
Co-authored-by: Isaac
longvu-db
changed the title
Add 3 new tests that create a DataFrame ONCE and reuse it across external mutations (data write, schema change, drop/recreate). These tests would FAIL in classic Spark (where the resolved plan is captured at DataFrame creation time) but PASS in Connect (where each action re-sends the plan for fresh server-side analysis). This makes the suite genuinely Connect-specific, not just a copy of the classic tests with Connect infrastructure. Co-authored-by: Isaac
Co-authored-by: Isaac
Adds 3 Connect tests verifying that when a DSv2 connector caches table state, external changes are invisible through repeated sql() calls. Co-authored-by: Isaac
Co-authored-by: Isaac
CachingInMemoryTableCatalog.clearCache() must run AFTER DROP TABLE, not before. Otherwise DROP TABLE re-caches the table via loadTable(), and the next test's CREATE TABLE hits a stale cache entry. Co-authored-by: Isaac
Co-authored-by: Isaac
Co-authored-by: Isaac
… sql() tests After asserting stale data with the caching connector, REFRESH TABLE invalidates the connector cache and verifies external changes become visible. Also adds invalidateTable override to CachingInMemoryTableCatalog. Co-authored-by: Isaac
…ng tests Move each cache test next to its corresponding external test with matching section numbers. Also adds invalidateTable override to CachingInMemoryTableCatalog for REFRESH TABLE support. Co-authored-by: Isaac
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
1 participant
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.
What changes were proposed in this pull request?
Add 6 tests in a new
DataSourceV2RepeatedSQLConnectSuitethat verify DSv2 tables reflect the latest state when accessed repeatedly viasql()in Spark Connect mode (without CACHE TABLE). Eachsql("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:sql()query sees the new data.sql()query reflects the updated schema.sql()query sees the empty recreated table.External writes use
getServerSession()to access the server-side catalog API (loadTablewith 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:Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code (claude-opus-4-6)