Skip to content

GH-1382: Implement JDBC type discovery with GetXdbcTypeInfo - #1391

Open
hutiefang76 wants to merge 2 commits into
apache:mainfrom
hutiefang76:frank/arrow1382-type-info-20261024
Open

hutiefang76 wants to merge 2 commits into
apache:mainfrom
hutiefang76:frank/arrow1382-type-info-20261024

Conversation

@hutiefang76

@hutiefang76 hutiefang76 commented Oct 24, 2026 •

Copy link
Copy Markdown
Contributor

What changed

Forward JDBC DatabaseMetaData.getTypeInfo() to GetXdbcTypeInfo and map the response to the 18 JDBC columns. Preserve server row order and SQL NULLs, convert parameter lists to strings and the JDBC short-valued fields to SMALLINT, and retain the standard column schema for empty results.

Servers that report UNIMPLEMENTED while fetching FlightInfo or initializing the type-info stream retain the previous empty JDBC result. Other Flight failures surface as SQLException. Real in-process Flight tests cover normal and multiple batches, unknown precision, NULL versus empty parameter lists, unsupported calls, server failures and allocator buffers returning to baseline after close.

Validation on macOS arm64, JDK 21.0.10, using the repository-pinned Arrow test data:

  • With identical final regression bytes, the reviewed production revision 024a13b4 fails the two unsupported-server cases; the follow-up passes all 11 focused tests, with no failures, errors or skips.
  • The affected Flight SQL/JDBC reactor passed offline verify, including Checkstyle, Spotless and driver packaging: Flight SQL 97 tests; JDBC Core 1255 records, including 44 existing conditional skips; packaged driver validation 2 integration tests. Dependency modules retain their existing conditional skips. The optional SBOM goal requires online mode and is skipped in this offline run.
  • Earlier feature verification established eight failures among nine focused cases against pre-feature production. An earlier full run encountered the unchanged ResultSetTest.testFallbackUnresolvableFlightServer timing assertion; one unchanged complete rerun passed. The current review follow-up's full verification passed on its first attempt.

Closes #1382.

Upstream CI and final review for this follow-up remain pending. The required enhancement classification label is missing, and this account cannot add it.

AI-generated patch and PR description using Codex and DeepSeek, with automated review by DeepSeek. The builds and test results above were executed locally.

Expose server type information through the existing Flight SQL JDBC metadata
bridge. Convert the protocol fields to the standard JDBC columns, preserve
nullable values and server order, and retain the empty-result schema.

Cover real client/server round trips across batches, parameter list conversion,
unknown precision, errors and allocator cleanup.

Generated-by: Codex
Generated-by: DeepSeek V4 Flash
@github-actions

Copy link
Copy Markdown

Thank you for opening a pull request!

Please label the PR with one or more of:

  • bug-fix
  • chore
  • dependencies
  • documentation
  • enhancement

Also, add the 'breaking-change' label if appropriate.

See CONTRIBUTING.md for details.

Comment on lines +1036 to +1038
flightInfoTypeInfo = connection.getClientHandler().getXdbcTypeInfo();
} catch (final FlightRuntimeException e) {
throw new SQLException("Failed to retrieve type info.", e);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This changes the behavior. getTypeInfo() used to return an empty 18-column result set without any RPC. Now any FlightRuntimeException becomes a SQLException, including UNIMPLEMENTED from servers that don't support CommandGetXdbcTypeInfo. BI tools and ORMs commonly call getTypeInfo() while setting up a connection, so those servers would now fail to connect.

Could we catch CallStatus.UNIMPLEMENTED here (and later), and return super.getTypeInfo() as before?
Only other failures should surface as SQLException.

Maybe we could add a test using setTypeInfoFlightInfoFailure(CallStatus.UNIMPLEMENTED..).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Implemented in 284386d: both getFlightInfo and stream initialization now fall back to super.getTypeInfo() for UNIMPLEMENTED. Other Flight failures still become SQLException.

Two real Flight-server regressions check the empty 18-column JDBC schema, no rows and allocator buffers returning to baseline. With identical final test bytes, the reviewed production revision failed those two cases; the fix passes all 11 focused tests. Local affected-reactor verification also passed: Flight SQL 97 tests; JDBC Core 1255 records, including 44 existing skips; packaged driver validation 2 integration tests. Upstream CI results for this follow-up remain pending.

AI-assisted patch and reply using DeepSeek and Codex; the tests above were executed locally.

Fall back to the legacy empty JDBC result when type discovery is unimplemented.

Generated-by: DeepSeek
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.

[Flight SQL][JDBC] Implement DatabaseMetaData.getTypeInfo via GetXdbcTypeInfo

2 participants