Skip to content

[SPARK-55441][SQL] Types Framework - Phase 1c - Client Integration#54905

Draft
davidm-db wants to merge 8 commits intoapache:masterfrom
davidm-db:davidm-db/types_framework_1c
Draft

[SPARK-55441][SQL] Types Framework - Phase 1c - Client Integration#54905
davidm-db wants to merge 8 commits intoapache:masterfrom
davidm-db:davidm-db/types_framework_1c

Conversation

@davidm-db
Copy link
Contributor

What changes were proposed in this pull request?

Extends the Types Framework (Phase 1a: #54223) with optional traits for client-facing infrastructure dispatch. Adds 4 new traits and integrates 13 files so that new framework-managed types get client support automatically — zero edits to infrastructure files.

New traits:

  • CatalystTypeOps (catalyst) — serializer/deserializer expression building, Arrow field writers
  • ClientTypeOps (sql/api) — Arrow conversion, JDBC mapping, Python interop, Hive formatting, Thrift type ID
  • ProtoTypeOps (connect/common) — Spark Connect proto DataType and Literal conversions
  • ConnectArrowTypeOps (connect/common) — Connect Arrow serde (no feature flag — client must handle whatever the server sends)

TimeType serves as the reference implementation. One new per-type class (TimeTypeConnectOps) handles both Connect traits; the existing TimeTypeApiOps and TimeTypeOps gain mix-ins
for ClientTypeOps and CatalystTypeOps respectively.

All changes follow the established getOrElse pattern — framework dispatch before existing branches, existing code stays as fallback.

Why are the changes needed?

Without this, adding a new data type requires manually editing 13+ client integration files with diverse patterns. With these traits, a new type implements the relevant ops methods and all client infrastructure dispatches through the framework automatically.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

The feature flag is enabled by default in test environments (Utils.isTesting), so the entire existing test suite validates the framework code path. No new tests are added in this PR because the framework delegates to the same underlying logic that existing tests already cover.

In subsequent phases, the testing focus will be on:

  • Testing the framework itself (Ops interface contracts, roundtrip correctness, edge cases)
  • Designing a generalized testing mechanism that enforces proper test coverage for each type added through the framework

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

Co-authored with: claude-opus-4-6

@davidm-db davidm-db changed the title supporting various clients thorugh types framework [SPARK-55441][SQL] Types Framework - Phase 1c - Client Integration Mar 19, 2026
Map("typeInfo" -> s"${literalCase.name}(${literalCase.getNumber})"))
}
builder.build()
ProtoTypeOps
Copy link
Contributor Author

@davidm-db davidm-db Mar 20, 2026

Choose a reason for hiding this comment

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

there doesn't seem to be a way to nicely/cleanly reduce the diff here

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