refactor: unify ResultSet implementations on Arrow-backed path by mkaufmann · Pull Request #175 · forcedotcom/datacloud-jdbc

mkaufmann · 2026-04-24T19:05:38Z

Summary

Collapse the two ResultSet families (streaming Arrow + row-based metadata) onto a single Arrow-backed pipeline so there is one accessor implementation, one set of type semantics, and one place to fix bugs. Tighten root-allocator hygiene end-to-end while we are in there, and bring getTypeInfo() and integer-column accessor coercion into line with JDBC 4.2.

Why

The driver previously carried two parallel result-set implementations: StreamingResultSet for query results (Arrow IPC, columnar accessors) and SimpleResultSet / DataCloudMetadataResultSet / ColumnAccessor for metadata (row-oriented List<List<Object>>, hand-rolled per-cell coercion). Same JDBC surface, two divergent code paths. Bugs found in one were rarely fixed in the other; type semantics drifted (e.g. getBoolean on an integer column behaved differently between the two), and the metadata path silently toString()'d any payload you handed it. The pre-rebase review of this PR also surfaced several allocator leak windows and JDBC-spec compliance gaps that the unification made it natural to fix.

What changed

Unified result set. StreamingResultSet, DataCloudMetadataResultSet, SimpleResultSet, and ColumnAccessor are removed. Every JDBC metadata call (getTables, getColumns, getSchemas, getTypeInfo, the empty-metadata helpers) now flows through DataCloudResultSet via a new MetadataResultSets factory. MetadataResultSets builds a single-batch Arrow IPC stream by reusing VectorPopulator (the same code path the JDBC parameter encoder uses) and HyperTypeToArrow.toField, then hands the resulting reader + allocator to DataCloudResultSet.of.

DataCloudResultSet is now a public class rather than the prior empty marker interface; the concrete implementation is no longer a sibling type called StreamingResultSet. The of(...) factory takes a QueryResultArrowStream.Result (reader + allocator pair) and owns both their lifecycles.

Root allocator hygiene. Six independent leak windows closed:

QueryResultArrowStream.toArrowStreamReader returns a Result holder that pairs reader + allocator and closes both in order (reader first so ArrowBuf accounting clears before the allocator's budget check). The 100 MB cap moves to a public ROOT_ALLOCATOR_BUDGET_BYTES constant and is now reused by the metadata path.
MetadataResultSets.of and QueryResultArrowStream.toArrowStreamReader both wrap allocator + reader construction in try/catch so the allocator is closed if new ArrowStreamReader(...) ever throws before ownership transfers.
DataCloudResultSet.of's construction-failure cleanup now wraps both reader.close and allocator.close with addSuppressed so neither close masks the original SQLException.
ArrowStreamReaderCursor.close uses try-with-resources over (allocator, reader) so reader closes first and any allocator-close exception attaches as suppressed onto the reader's instead of replacing it.
DataCloudStatement.executeQuery and getResultSet hoist iterator.getQueryStatus().getQueryId() once before allocator construction, so a throw between allocator creation and DataCloudResultSet.of taking ownership can no longer strand the allocator.
DataCloudResultSet.close is idempotent across cursor.close failures: the closed flag flips before delegating, so a defensive caller's retry is a no-op rather than a double-close.

JDBC spec compliance.

getTypeInfo() boolean columns (CASE_SENSITIVE, UNSIGNED_ATTRIBUTE, FIXED_PREC_SCALE, AUTO_INCREMENT) are now declared as BOOLEAN per JDBC 4.2 (DatabaseMetaData.getTypeInfo Javadoc) and pgjdbc, via a new bool(...) helper in MetadataSchemas. They were previously declared as text(...) while the row producer wrote raw Boolean values, which only "worked" because VarCharVectorSetter silently toString()'d everything.
BaseIntVectorAccessor.getBoolean now matches ResultSet.getBoolean's spec text on integer columns: 0 returns false, 1 returns true, anything else throws SQLException with SQLState 22018 (matching pgjdbc's strict CANNOT_COERCE behavior in BooleanTypeUtil.fromNumber). Previously inherited the abstract default that threw SQLFeatureNotSupportedException for everything.
VectorPopulator.VarCharVectorSetter is tightened from <VarCharVector, Object> to <VarCharVector, String>, so non-String payloads fail fast at the BaseVectorSetter type guard. The byte[] arm was dead — setBytes / setBinaryStream / setUnicodeStream / setAsciiStream all throw FEATURE_NOT_SUPPORTED in DataCloudPreparedStatement.
Integer-family setters (IntVectorSetter, SmallIntVectorSetter, TinyIntVectorSetter) now range-check before narrowing rather than silently truncating; DecimalVectorSetter does the same via a bitLength() > 63 guard on the unscaled value.
QueryJDBCAccessor.getObject(Class) gains an isInstance fallback so getObject(col, String.class) on a VARCHAR (and analogous identity-class paths on every other accessor) works without each accessor implementing typed getObject itself.

Observable behavior changes

rs.getBoolean("CASE_SENSITIVE") on getTypeInfo() returns a real Boolean (was SQLFeatureNotSupportedException via the broken VARCHAR path).
rs.getBoolean("NULLABLE") on getColumns() (and any other integer column) returns false for 0 and true for 1, instead of throwing. Other integer values throw SQLException (SQLState 22018).
rs.getDate(intCol) / getTime(intCol) / getTimestamp(intCol) on metadata rows throw SQLException (was UnsupportedOperationException).
rs.getObject(intCol, Boolean.class) on metadata rows now throws (the strict isInstance path).
rs.getMetaData().getColumnType(...) on the four getTypeInfo() boolean columns returns Types.BOOLEAN, not Types.VARCHAR.
rs.getMetaData().getColumnTypeName(...) on every metadata result set (getTables, getColumns, getTypeInfo, …) returns the JDBC type name derived from the column's HyperType ("VARCHAR", "SMALLINT", "INTEGER", "BOOLEAN") rather than the prior Hyper-flavored labels ("TEXT", "SHORT", "INTEGER", "BOOL"). The JDBC spec only requires some database-specific type name and does not pin specific strings; this aligns with the names other JDBC consumers in the driver already use.
ps.setObject(idx, x, Types.VARCHAR) with a non-String / non-byte[] argument now throws IllegalArgumentException instead of silently toString()-ing the argument.
ps.setObject(idx, x, Types.INTEGER) (and INT2/INT8) throws IllegalArgumentException for out-of-range Numbers instead of silently narrowing; same for Types.DECIMAL when the unscaled value exceeds 64 bits.

Breaking changes

com.salesforce.datacloud.jdbc.core.DataCloudResultSet is now a public class rather than a public interface. External code that wrote class MyRs implements DataCloudResultSet (decorators, wrappers, hand-rolled doubles) no longer compiles; code that consumes the standard java.sql.ResultSet / DataCloudResultSet API as an opaque type recompiles unchanged.

The previously-public types StreamingResultSet, DataCloudMetadataResultSet, SimpleResultSet, ColumnAccessor are removed. External callers of StreamingResultSet.of(ArrowStreamReader, ...) should switch to DataCloudResultSet.of(QueryResultArrowStream.Result, ...).

Test plan

./gradlew :jdbc-core:test — full module suite green.
./gradlew :jdbc-core:spotlessCheck — formatting clean.
./gradlew clean build — full build including :spark-datasource, JaCoCo coverage, verification.
New tests pin the load-bearing invariants: MetadataSchemasTest adds three TYPE_INFO position-by-position assertions; VarCharVectorSetterStrictTypeTest regresses on Boolean / byte[] / Number payloads; IntegerVectorSetterRangeCheckTest extends to DecimalVectorSetter; ArrowStreamReaderCursorTest pins reader-before-allocator close ordering plus addSuppressed chaining when both throw; DataCloudResultSetMethodTest pins close() idempotence under cursor.close failure; DataCloudDatabaseMetadataTest.testGetTypeInfo now exercises getBoolean on all four boolean columns end-to-end.

BREAKING CHANGE: DataCloudResultSet is now a class instead of an interface; StreamingResultSet, DataCloudMetadataResultSet, SimpleResultSet, ColumnAccessor are removed; metadata int-column getDate/getTime/getTimestamp throw SQLException (was UnsupportedOperationException); getTypeInfo() boolean columns are typed BOOLEAN instead of VARCHAR (getObject returns Boolean, not String); getColumnTypeName on metadata result sets returns the JDBC type name (VARCHAR/SMALLINT/INTEGER/BOOLEAN) instead of the prior Hyper-flavored labels (TEXT/SHORT/INTEGER/BOOL); ps.setObject with Types.VARCHAR rejects non-String/byte[] payloads; integer-family and DECIMAL setters reject out-of-range values instead of silently narrowing.

…ArrowStreamReader Rework the ResultSet unification to address two reviewer requests on #175: 1. Share the vector-building code with the parameter-encoding path instead of having a dedicated MetadataArrowBuilder. VectorPopulator now exposes a row-indexed primitive (setCell) used by both callers. The existing single-row parameter-binding overload and a new many-row metadata overload both funnel through it, and all the individual vector setters are parameterised by row index. 2. Keep ArrowStreamReaderCursor on its original ArrowStreamReader-only interface. The metadata path now serialises a populated VSR to Arrow IPC bytes and wraps the result in a ByteArrayInputStream-backed ArrowStreamReader, so both streaming and metadata result sets travel through exactly the same reader/cursor plumbing. Supporting changes: - typeName overrides (e.g. "TEXT" for JDBC-spec metadata columns) now round-trip through Arrow via a jdbc:type_name field-metadata key rather than a columns-override parameter on StreamingResultSet. HyperTypeToArrow stamps the key on write; ArrowToHyperTypeMapper.toColumnMetadata reads it back. - StreamingResultSet drops the ofInMemory(...) factory and the columns override; callers construct an ArrowStreamReader + BufferAllocator pair and hand them to of(reader, allocator, queryId, zone). The cursor owns both and closes reader-then-allocator on close. - QueryResultArrowStream.toArrowStreamReader returns a simple Result holder (reader + allocator) instead of an AutoCloseable bundle. - MetadataResultSets is the single entry point for Arrow-backed metadata result sets; MetadataArrowBuilder is deleted. - Empty metadata results skip writeBatch() entirely so ArrowStreamReaderCursor doesn't interpret a zero-row batch as "at least one row available". - Tests updated to the new API; StreamingResultSetMethodTest builds its in-memory ResultSet the same way as the metadata path (IPC round-trip).

codecov · 2026-05-11T13:44:21Z

Codecov Report

❌ Patch coverage is 75.13514% with 92 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.51%. Comparing base (f47714f) to head (96925fd).

Files with missing lines	Patch %	Lines
...sforce/datacloud/jdbc/core/DataCloudResultSet.java	75.75%	47 Missing and 1 partial ⚠️
...tacloud/jdbc/core/metadata/MetadataResultSets.java	65.45%	15 Missing and 4 partials ⚠️
.../datacloud/jdbc/protocol/data/VectorPopulator.java	76.11%	11 Missing and 5 partials ⚠️
...atacloud/jdbc/protocol/QueryResultArrowStream.java	25.00%	6 Missing ⚠️
...jdbc/core/accessor/impl/BaseIntVectorAccessor.java	66.66%	1 Missing and 1 partial ⚠️
...e/datacloud/jdbc/core/ArrowStreamReaderCursor.java	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #175      +/-   ##
============================================
- Coverage     82.37%   80.51%   -1.87%     
+ Complexity     1871     1703     -168     
============================================
  Files           125      122       -3     
  Lines          5020     4941      -79     
  Branches        540      520      -20     
============================================
- Hits           4135     3978     -157     
- Misses          642      735      +93     
+ Partials        243      228      -15

Components	Coverage Δ
JDBC Core	`80.86% <75.13%> (-2.29%)`	⬇️
JDBC Main	`40.69% <ø> (ø)`
JDBC HTTP	`90.30% <ø> (ø)`
JDBC Utilities	`65.25% <ø> (ø)`
Spark Datasource	`∅ <ø> (∅)`

Files with missing lines	Coverage Δ
...force/datacloud/jdbc/core/DataCloudConnection.java	`57.04% <100.00%> (ø)`
...datacloud/jdbc/core/DataCloudDatabaseMetadata.java	`98.34% <100.00%> (-0.01%)`	⬇️
...sforce/datacloud/jdbc/core/DataCloudStatement.java	`80.90% <100.00%> (-0.20%)`	⬇️
...alesforce/datacloud/jdbc/core/MetadataSchemas.java	`96.87% <100.00%> (+0.04%)`	⬆️
...esforce/datacloud/jdbc/core/QueryMetadataUtil.java	`95.40% <100.00%> (ø)`
...oud/jdbc/core/SQLExceptionQueryResultIterator.java	`75.00% <ø> (ø)`
...jdbc/core/metadata/DataCloudResultSetMetaData.java	`80.48% <100.00%> (-5.56%)`	⬇️
...oud/jdbc/protocol/data/ArrowToHyperTypeMapper.java	`67.85% <100.00%> (+6.03%)`	⬆️
...datacloud/jdbc/protocol/data/HyperTypeToArrow.java	`76.74% <100.00%> (-1.52%)`	⬇️
.../com/salesforce/datacloud/jdbc/util/Constants.java	`0.00% <ø> (ø)`
... and 6 more

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

…ArrowStreamReader Rework the ResultSet unification to address two reviewer requests on #175: 1. Share the vector-building code with the parameter-encoding path instead of having a dedicated MetadataArrowBuilder. VectorPopulator now exposes a row-indexed primitive (setCell) used by both callers. The existing single-row parameter-binding overload and a new many-row metadata overload both funnel through it, and all the individual vector setters are parameterised by row index. 2. Keep ArrowStreamReaderCursor on its original ArrowStreamReader-only interface. The metadata path now serialises a populated VSR to Arrow IPC bytes and wraps the result in a ByteArrayInputStream-backed ArrowStreamReader, so both streaming and metadata result sets travel through exactly the same reader/cursor plumbing. Supporting changes: - typeName overrides (e.g. "TEXT" for JDBC-spec metadata columns) now round-trip through Arrow via a jdbc:type_name field-metadata key rather than a columns-override parameter on StreamingResultSet. HyperTypeToArrow stamps the key on write; ArrowToHyperTypeMapper.toColumnMetadata reads it back. - StreamingResultSet drops the ofInMemory(...) factory and the columns override; callers construct an ArrowStreamReader + BufferAllocator pair and hand them to of(reader, allocator, queryId, zone). The cursor owns both and closes reader-then-allocator on close. - QueryResultArrowStream.toArrowStreamReader returns a simple Result holder (reader + allocator) instead of an AutoCloseable bundle. - MetadataResultSets is the single entry point for Arrow-backed metadata result sets; MetadataArrowBuilder is deleted. - Empty metadata results skip writeBatch() entirely so ArrowStreamReaderCursor doesn't interpret a zero-row batch as "at least one row available". - Tests updated to the new API; StreamingResultSetMethodTest builds its in-memory ResultSet the same way as the metadata path (IPC round-trip).

Now that QueryJDBCAccessor.getObject(Class) provides the raw + isInstance fallback as its base-class default, StreamingResultSet no longer needs the catch-and-retry path that worked around accessors which threw "Operation not supported." Collapse getObject(int, Class) to direct dispatch and update the regression test's WHY comment to point at the accessor base class as the load-bearing layer. Addresses: review comment on PR #175 line 388.

Three small follow-ups from PR #175 review: - StreamingResultSet.of: drop the paragraph that pointed at the HyperTypeToArrow.JDBC_TYPE_NAME_METADATA_KEY field-metadata key. The docstring spilled implementation detail of the metadata-stamping path into a generic "create a result set from a reader" entry-point; the type-name override is documented at HyperTypeToArrow / ColumnMetadata where it's relevant. - ArrowStreamReaderCursor.loadNextNonEmptyBatch: rewrite the rationale to answer "why does the cursor consume empty batches instead of the caller?" directly. Empty IPC batches are valid Arrow and producers emit them; JDBC's next() only knows rows, so this cursor is the seam that translates batch-level signals into row-level advances. - MetadataResultSetsTest: drop the JDBC ResultSet-shape slice (next / isClosed / getStatement / unwrap / isWrapperFor / getHoldability / getFetchSize / setFetchSize / getWarnings / getConcurrency / getType / getFetchDirection). Those test the StreamingResultSet plumbing shared by every result set on this branch and are already covered by StreamingResultSetMethodTest. Keep the arity-contract slice (short/long/right/null/empty rows) — that is the metadata-result-set-specific behavior. Addresses: review comments on PR #175.

…ArrowStreamReader Rework the ResultSet unification to address two reviewer requests on #175: 1. Share the vector-building code with the parameter-encoding path instead of having a dedicated MetadataArrowBuilder. VectorPopulator now exposes a row-indexed primitive (setCell) used by both callers. The existing single-row parameter-binding overload and a new many-row metadata overload both funnel through it, and all the individual vector setters are parameterised by row index. 2. Keep ArrowStreamReaderCursor on its original ArrowStreamReader-only interface. The metadata path now serialises a populated VSR to Arrow IPC bytes and wraps the result in a ByteArrayInputStream-backed ArrowStreamReader, so both streaming and metadata result sets travel through exactly the same reader/cursor plumbing. Supporting changes: - typeName overrides (e.g. "TEXT" for JDBC-spec metadata columns) now round-trip through Arrow via a jdbc:type_name field-metadata key rather than a columns-override parameter on StreamingResultSet. HyperTypeToArrow stamps the key on write; ArrowToHyperTypeMapper.toColumnMetadata reads it back. - StreamingResultSet drops the ofInMemory(...) factory and the columns override; callers construct an ArrowStreamReader + BufferAllocator pair and hand them to of(reader, allocator, queryId, zone). The cursor owns both and closes reader-then-allocator on close. - QueryResultArrowStream.toArrowStreamReader returns a simple Result holder (reader + allocator) instead of an AutoCloseable bundle. - MetadataResultSets is the single entry point for Arrow-backed metadata result sets; MetadataArrowBuilder is deleted. - Empty metadata results skip writeBatch() entirely so ArrowStreamReaderCursor doesn't interpret a zero-row batch as "at least one row available". - Tests updated to the new API; StreamingResultSetMethodTest builds its in-memory ResultSet the same way as the metadata path (IPC round-trip).

Now that QueryJDBCAccessor.getObject(Class) provides the raw + isInstance fallback as its base-class default, StreamingResultSet no longer needs the catch-and-retry path that worked around accessors which threw "Operation not supported." Collapse getObject(int, Class) to direct dispatch and update the regression test's WHY comment to point at the accessor base class as the load-bearing layer. Addresses: review comment on PR #175 line 388.

Three small follow-ups from PR #175 review: - StreamingResultSet.of: drop the paragraph that pointed at the HyperTypeToArrow.JDBC_TYPE_NAME_METADATA_KEY field-metadata key. The docstring spilled implementation detail of the metadata-stamping path into a generic "create a result set from a reader" entry-point; the type-name override is documented at HyperTypeToArrow / ColumnMetadata where it's relevant. - ArrowStreamReaderCursor.loadNextNonEmptyBatch: rewrite the rationale to answer "why does the cursor consume empty batches instead of the caller?" directly. Empty IPC batches are valid Arrow and producers emit them; JDBC's next() only knows rows, so this cursor is the seam that translates batch-level signals into row-level advances. - MetadataResultSetsTest: drop the JDBC ResultSet-shape slice (next / isClosed / getStatement / unwrap / isWrapperFor / getHoldability / getFetchSize / setFetchSize / getWarnings / getConcurrency / getType / getFetchDirection). Those test the StreamingResultSet plumbing shared by every result set on this branch and are already covered by StreamingResultSetMethodTest. Keep the arity-contract slice (short/long/right/null/empty rows) — that is the metadata-result-set-specific behavior. Addresses: review comments on PR #175.

mkaufmann · 2026-05-11T17:06:39Z

Per the two review threads, split out the cherry-pickable fixes as their own PRs against main:

chore: skip zero-row batches in ArrowStreamReaderCursor #185 — fix: skip zero-row batches in ArrowStreamReaderCursor (commit 2088116 from this branch, reshaped against main's 2-arg cursor signature). Self-contained: only ArrowStreamReaderCursor.java + ArrowStreamReaderCursorTest.java.
fix: support getObject(Class) with identity class type in QueryJDBCAccessor #186 — fix: provide default getObject(Class) fallback in QueryJDBCAccessor (commit 093d692 from this branch, applies cleanly on main). Self-contained: only QueryJDBCAccessor.java + the bundled StreamingResultSetMethodTest.getObjectWithClassUsesAccessorBaseFallback regression test.

This PR (#175) keeps the same fixes as the first two commits — when #185 / #186 land, those commits will collapse to no-ops at rebase time.

For the remaining "should QueryResultArrowStream allocator-ownership move pre-unify too?" thread (#175 review): waiting on your call before I do that split. As I noted there, it's a non-trivial surgery on the unify commit and I'd rather get your sign-off before rewriting ~800 lines of refactor.

…ArrowStreamReader Rework the ResultSet unification to address two reviewer requests on #175: 1. Share the vector-building code with the parameter-encoding path instead of having a dedicated MetadataArrowBuilder. VectorPopulator now exposes a row-indexed primitive (setCell) used by both callers. The existing single-row parameter-binding overload and a new many-row metadata overload both funnel through it, and all the individual vector setters are parameterised by row index. 2. Keep ArrowStreamReaderCursor on its original ArrowStreamReader-only interface. The metadata path now serialises a populated VSR to Arrow IPC bytes and wraps the result in a ByteArrayInputStream-backed ArrowStreamReader, so both streaming and metadata result sets travel through exactly the same reader/cursor plumbing. Supporting changes: - typeName overrides (e.g. "TEXT" for JDBC-spec metadata columns) now round-trip through Arrow via a jdbc:type_name field-metadata key rather than a columns-override parameter on StreamingResultSet. HyperTypeToArrow stamps the key on write; ArrowToHyperTypeMapper.toColumnMetadata reads it back. - StreamingResultSet drops the ofInMemory(...) factory and the columns override; callers construct an ArrowStreamReader + BufferAllocator pair and hand them to of(reader, allocator, queryId, zone). The cursor owns both and closes reader-then-allocator on close. - QueryResultArrowStream.toArrowStreamReader returns a simple Result holder (reader + allocator) instead of an AutoCloseable bundle. - MetadataResultSets is the single entry point for Arrow-backed metadata result sets; MetadataArrowBuilder is deleted. - Empty metadata results skip writeBatch() entirely so ArrowStreamReaderCursor doesn't interpret a zero-row batch as "at least one row available". - Tests updated to the new API; StreamingResultSetMethodTest builds its in-memory ResultSet the same way as the metadata path (IPC round-trip).

Now that QueryJDBCAccessor.getObject(Class) provides the raw + isInstance fallback as its base-class default, StreamingResultSet no longer needs the catch-and-retry path that worked around accessors which threw "Operation not supported." Collapse getObject(int, Class) to direct dispatch and update the regression test's WHY comment to point at the accessor base class as the load-bearing layer. Addresses: review comment on PR #175 line 388.

Three small follow-ups from PR #175 review: - StreamingResultSet.of: drop the paragraph that pointed at the HyperTypeToArrow.JDBC_TYPE_NAME_METADATA_KEY field-metadata key. The docstring spilled implementation detail of the metadata-stamping path into a generic "create a result set from a reader" entry-point; the type-name override is documented at HyperTypeToArrow / ColumnMetadata where it's relevant. - ArrowStreamReaderCursor.loadNextNonEmptyBatch: rewrite the rationale to answer "why does the cursor consume empty batches instead of the caller?" directly. Empty IPC batches are valid Arrow and producers emit them; JDBC's next() only knows rows, so this cursor is the seam that translates batch-level signals into row-level advances. - MetadataResultSetsTest: drop the JDBC ResultSet-shape slice (next / isClosed / getStatement / unwrap / isWrapperFor / getHoldability / getFetchSize / setFetchSize / getWarnings / getConcurrency / getType / getFetchDirection). Those test the StreamingResultSet plumbing shared by every result set on this branch and are already covered by StreamingResultSetMethodTest. Keep the arity-contract slice (short/long/right/null/empty rows) — that is the metadata-result-set-specific behavior. Addresses: review comments on PR #175.

…ArrowStreamReader Rework the ResultSet unification to address two reviewer requests on #175: 1. Share the vector-building code with the parameter-encoding path instead of having a dedicated MetadataArrowBuilder. VectorPopulator now exposes a row-indexed primitive (setCell) used by both callers. The existing single-row parameter-binding overload and a new many-row metadata overload both funnel through it, and all the individual vector setters are parameterised by row index. 2. Keep ArrowStreamReaderCursor on its original ArrowStreamReader-only interface. The metadata path now serialises a populated VSR to Arrow IPC bytes and wraps the result in a ByteArrayInputStream-backed ArrowStreamReader, so both streaming and metadata result sets travel through exactly the same reader/cursor plumbing. Supporting changes: - typeName overrides (e.g. "TEXT" for JDBC-spec metadata columns) now round-trip through Arrow via a jdbc:type_name field-metadata key rather than a columns-override parameter on StreamingResultSet. HyperTypeToArrow stamps the key on write; ArrowToHyperTypeMapper.toColumnMetadata reads it back. - StreamingResultSet drops the ofInMemory(...) factory and the columns override; callers construct an ArrowStreamReader + BufferAllocator pair and hand them to of(reader, allocator, queryId, zone). The cursor owns both and closes reader-then-allocator on close. - QueryResultArrowStream.toArrowStreamReader returns a simple Result holder (reader + allocator) instead of an AutoCloseable bundle. - MetadataResultSets is the single entry point for Arrow-backed metadata result sets; MetadataArrowBuilder is deleted. - Empty metadata results skip writeBatch() entirely so ArrowStreamReaderCursor doesn't interpret a zero-row batch as "at least one row available". - Tests updated to the new API; StreamingResultSetMethodTest builds its in-memory ResultSet the same way as the metadata path (IPC round-trip).

Now that QueryJDBCAccessor.getObject(Class) provides the raw + isInstance fallback as its base-class default, StreamingResultSet no longer needs the catch-and-retry path that worked around accessors which threw "Operation not supported." Collapse getObject(int, Class) to direct dispatch and update the regression test's WHY comment to point at the accessor base class as the load-bearing layer. Addresses: review comment on PR #175 line 388.

Three small follow-ups from PR #175 review: - StreamingResultSet.of: drop the paragraph that pointed at the HyperTypeToArrow.JDBC_TYPE_NAME_METADATA_KEY field-metadata key. The docstring spilled implementation detail of the metadata-stamping path into a generic "create a result set from a reader" entry-point; the type-name override is documented at HyperTypeToArrow / ColumnMetadata where it's relevant. - ArrowStreamReaderCursor.loadNextNonEmptyBatch: rewrite the rationale to answer "why does the cursor consume empty batches instead of the caller?" directly. Empty IPC batches are valid Arrow and producers emit them; JDBC's next() only knows rows, so this cursor is the seam that translates batch-level signals into row-level advances. - MetadataResultSetsTest: drop the JDBC ResultSet-shape slice (next / isClosed / getStatement / unwrap / isWrapperFor / getHoldability / getFetchSize / setFetchSize / getWarnings / getConcurrency / getType / getFetchDirection). Those test the StreamingResultSet plumbing shared by every result set on this branch and are already covered by StreamingResultSetMethodTest. Keep the arity-contract slice (short/long/right/null/empty rows) — that is the metadata-result-set-specific behavior. Addresses: review comments on PR #175.

…ArrowStreamReader Rework the ResultSet unification to address two reviewer requests on #175: 1. Share the vector-building code with the parameter-encoding path instead of having a dedicated MetadataArrowBuilder. VectorPopulator now exposes a row-indexed primitive (setCell) used by both callers. The existing single-row parameter-binding overload and a new many-row metadata overload both funnel through it, and all the individual vector setters are parameterised by row index. 2. Keep ArrowStreamReaderCursor on its original ArrowStreamReader-only interface. The metadata path now serialises a populated VSR to Arrow IPC bytes and wraps the result in a ByteArrayInputStream-backed ArrowStreamReader, so both streaming and metadata result sets travel through exactly the same reader/cursor plumbing. Supporting changes: - typeName overrides (e.g. "TEXT" for JDBC-spec metadata columns) now round-trip through Arrow via a jdbc:type_name field-metadata key rather than a columns-override parameter on StreamingResultSet. HyperTypeToArrow stamps the key on write; ArrowToHyperTypeMapper.toColumnMetadata reads it back. - StreamingResultSet drops the ofInMemory(...) factory and the columns override; callers construct an ArrowStreamReader + BufferAllocator pair and hand them to of(reader, allocator, queryId, zone). The cursor owns both and closes reader-then-allocator on close. - QueryResultArrowStream.toArrowStreamReader returns a simple Result holder (reader + allocator) instead of an AutoCloseable bundle. - MetadataResultSets is the single entry point for Arrow-backed metadata result sets; MetadataArrowBuilder is deleted. - Empty metadata results skip writeBatch() entirely so ArrowStreamReaderCursor doesn't interpret a zero-row batch as "at least one row available". - Tests updated to the new API; StreamingResultSetMethodTest builds its in-memory ResultSet the same way as the metadata path (IPC round-trip).

StreamingResultSet.of catches IOException and IllegalArgumentException from the Arrow schema decode and rewraps as SQLException. At all four query-path call sites (DataCloudConnection.getRowBasedResultSet, getChunkBasedResultSet, DataCloudStatement.executeQuery, getResultSet) the surrounding try-catch only catches StatusRuntimeException, so a SQLException thrown from of() bypasses it and leaks the 100 MB RootAllocator returned by QueryResultArrowStream.toArrowStreamReader. Introduce StreamingResultSet.ofClosingOnFailure(Result, queryId, sessionZone) that takes the reader+allocator pair and closes both on construction failure (reader first so its buffers release before the allocator's budget check). Switch all four call sites to it. The metadata path in MetadataResultSets.of already had this shape; this fixes the matching gap on the query side. Add a regression test that builds an Arrow IPC stream with an unsupported field type (LargeUtf8) and asserts the helper closes both the reader and the allocator on the resulting SQLException.

The Int/SmallInt/TinyInt setters widened from concrete boxed types (Integer/Short/Byte) to Number so metadata rows could pass long values, but lost the implicit "right boxed type" check at the call sites that went through DataCloudPreparedStatement.setObject for parameter binding. A user binding Long.MAX_VALUE to an INT32 parameter would silently get (int) Long.MAX_VALUE = -1 written to the vector. Add an explicit range check on Int/SmallInt/TinyInt setters before narrowing. Both the metadata path and the parameter-binding path go through these setters, so strict checks here mean strict on both paths. BigInt accepts the full long range and is unchanged. Pin the behavior with a focused unit test (IntegerVectorSetterRangeCheckTest).

The driver round-trips JDBC-spec type-name overrides (e.g. "TEXT" for metadata columns) through Arrow field metadata under a custom key. The previous key "jdbc:type_name" used an unprefixed namespace not reserved by the Arrow spec — Hyper, query-federator, or another Arrow producer could emit a same-named key in a future protocol version, in which case ArrowToHyperTypeMapper would silently override its own derived type name with whatever upstream stamped. Rename to "datacloud-jdbc:type_name" so the namespace is unambiguous, and expand the field's javadoc to document the namespace rationale.

The fallback in ArrowToHyperTypeMapper.toColumnMetadata — when a field has no datacloud-jdbc:type_name override, ColumnMetadata.typeName is null and the JDBC layer derives the column type-name from the HyperType — was load-bearing but unasserted. Real Hyper Arrow streams never stamp the override, so every functional query test exercised the fallback implicitly; if a future refactor broke it, the regression would not surface in the existing suite. Two new pin tests: - ArrowToHyperTypeMapperTest at the unit boundary: field with override -> typeName matches; field without override (null metadata, empty metadata) -> typeName is null. - StreamingResultSetTest.getColumnTypeNameFallsBackToDerivedNameOnRealHyperStream end-to-end against local Hyper: executeQuery on a select with INT, VARCHAR, DECIMAL columns asserts ResultSetMetaData.getColumnTypeName returns the derived names ("INTEGER", "VARCHAR", "DECIMAL").

Drive-by pin test: StreamingResultSet.getObject(int, Map<String,Class<?>>) with a null or empty type map should behave like plain getObject(int) per the JDBC spec. Previously not asserted anywhere. The companion getObject(Class) fallback test landed earlier on this branch, bundled into the QueryJDBCAccessor base-class fix commit so the fix and its end-to-end coverage ship as a single cherry-pickable unit.

Previously a row with the wrong number of elements would silently leave the trailing columns as Arrow null (interpreted as missing values). Today every caller routes through MetadataSchemas so the sizes match by construction, but a future caller bug would surface only inside vector population, far from the boundary. Add an explicit arity check at the of(...) entrypoint: each non-null row must have exactly columns.size() elements. Null rows are accepted as the all-nulls row (matching the legacy coerceRows convention of turning null into emptyList). Empty rows are accepted only when the schema is also empty. Pin behavior with MetadataResultSetsTest covering short, long, correct-arity, null-row, and empty-rows cases.

Now that ArrowStreamReaderCursor.loadNextNonEmptyBatch (introduced earlier on this branch as a pre-unify cursor fix) consumes empty batches at the cursor seam, MetadataResultSets.writeArrowStream no longer needs its own "skip writeBatch when rowCount==0" workaround: the cursor handles the empty-only case correctly. Remove the special case and always emit a batch. Tightens the zeroRowOnlyBatchYieldsNoRows test docstring to match.

DataCloudMetadataResultSet was deleted in this PR, but the test file retained the old name and lived in the wrong package. Merge its empty- result-set JDBC-shape smoke tests into the new MetadataResultSetsTest under the .core.metadata package and delete the legacy file. No behavior change.

Now that QueryJDBCAccessor.getObject(Class) provides the raw + isInstance fallback as its base-class default, StreamingResultSet no longer needs the catch-and-retry path that worked around accessors which threw "Operation not supported." Collapse getObject(int, Class) to direct dispatch and update the regression test's WHY comment to point at the accessor base class as the load-bearing layer. Addresses: review comment on PR #175 line 388.

Three small follow-ups from PR #175 review: - StreamingResultSet.of: drop the paragraph that pointed at the HyperTypeToArrow.JDBC_TYPE_NAME_METADATA_KEY field-metadata key. The docstring spilled implementation detail of the metadata-stamping path into a generic "create a result set from a reader" entry-point; the type-name override is documented at HyperTypeToArrow / ColumnMetadata where it's relevant. - ArrowStreamReaderCursor.loadNextNonEmptyBatch: rewrite the rationale to answer "why does the cursor consume empty batches instead of the caller?" directly. Empty IPC batches are valid Arrow and producers emit them; JDBC's next() only knows rows, so this cursor is the seam that translates batch-level signals into row-level advances. - MetadataResultSetsTest: drop the JDBC ResultSet-shape slice (next / isClosed / getStatement / unwrap / isWrapperFor / getHoldability / getFetchSize / setFetchSize / getWarnings / getConcurrency / getType / getFetchDirection). Those test the StreamingResultSet plumbing shared by every result set on this branch and are already covered by StreamingResultSetMethodTest. Keep the arity-contract slice (short/long/right/null/empty rows) — that is the metadata-result-set-specific behavior. Addresses: review comments on PR #175.

StreamingResultSet had two public factories — of(reader, allocator, queryId[, zone]) (4 callers) and ofClosingOnFailure(Result, queryId, zone) (5 callers). Every production caller wanted the close-on-failure behavior; only tests and the metadata helper used the bare of(). Two factories with overlapping responsibilities is one too many — a caller hitting the bare of() and not knowing about ofClosingOnFailure would silently leak the 100 MB RootAllocator on construction failure. Collapse to one public factory: - of(QueryResultArrowStream.Result, queryId, sessionZone) — the only factory callers see, always closes both reader and allocator on failure. Name is the unambiguous "of" because there is no other. - create(reader, allocator, queryId, sessionZone) — private; just the construction body the factory wraps. Production call sites (DataCloudConnection, DataCloudStatement) and MetadataResultSets were already passing a (reader, allocator) pair, so the call shape collapses to passing the Result holder. Tests that were building the pair locally now wrap it in a Result the same way.

@Getter

…r interface Pre-unify there were three result-set implementations: StreamingResultSet (streaming Arrow query results), DataCloudMetadataResultSet (metadata), SimpleResultSet (in-memory rows). The DataCloudResultSet interface — a one-method (getQueryId) extension over java.sql.ResultSet — was the common "implements" the public API surfaced; StreamingResultSet was the only one that ever implemented it as a non-trivial impl. The unify refactor collapsed all three implementations into StreamingResultSet, but kept the interface and the "Streaming" name. Two problems fall out: - The "Streaming" name now lies. Metadata results flow through the same class but they're a one-shot in-memory IPC blob — nothing streaming about them. MetadataResultSets.of even passes /*queryId=*/ null because there is no query. - The DataCloudResultSet interface has one implementer and one method. Layering an interface for one impl is just a reader trap: callers instinctively look for "what other implementations exist" and find none. Collapse the two: - Rename the class StreamingResultSet -> DataCloudResultSet. - Delete the old DataCloudResultSet interface (the public method getQueryId() now lives directly on the class via @Getter). - Update all production and test references; rename the affected test files to match (StreamingResultSet*Test -> DataCloudResultSet*Test). The public API surface is unchanged in source for the common cases: DataCloudConnection.getRowBasedResultSet / getChunkBasedResultSet still return DataCloudResultSet, just as a class instead of an interface. This is binary-incompatible for any caller that ever cast to or implemented the old interface; in practice only StreamingResultSet implemented it on the read side, and no code outside the driver implemented it on the write side.

mkaufmann · 2026-05-15T10:20:34Z

Rebased on origin/main (now 7baf67d), force-pushed. :jdbc-core:test passes.

Walked the 10 inline findings against the rebased tree — all still apply. PRs #185 (zero-row batch skip) and #186 (getObject(Class) identity fallback) landed on main since the review and dropped out of this PR's diff cleanly, but neither touches any of the lines a finding anchors to. The IntegerVectorSetter range-check tightening called out in the summary is still on this branch (3bfd821).

GitHub now flags the inline comments as outdated because of the SHA rewrite. The findings themselves are unchanged — text and line anchors are still correct.

Generated by the review-pr-tavern skill — a human did not write this comment.

…torSetter DatabaseMetaData.getTypeInfo declared CASE_SENSITIVE, UNSIGNED_ATTRIBUTE, FIXED_PREC_SCALE, and AUTO_INCREMENT as VARCHAR while the row producer in HyperTypes.buildTypeInfoRow wrote Boolean values into them. The mismatch worked only because VarCharVectorSetter accepted Object and silently called value.toString(), so the four columns surfaced as "true"/"false" strings instead of the boolean payload JDBC 4.2 (DatabaseMetaData.getTypeInfo) and pgjdbc both define for these positions. Declare the four columns with a new bool(...) helper in MetadataSchemas that produces a HyperType.bool(true) / Constants.BOOL ColumnMetadata. The existing BitVectorSetter already accepts Boolean, so the row producer is unchanged. Tighten VarCharVectorSetter from BaseVectorSetter<VarCharVector, Object> to <VarCharVector, String> so non-String payloads fail fast at the BaseVectorSetter type guard instead of being toString-coerced — the byte[] arm was dead (setBytes / setBinaryStream / setUnicodeStream / setAsciiStream all throw FEATURE_NOT_SUPPORTED in DataCloudPreparedStatement). Both fixes land together because tightening the setter without the schema fix would make getTypeInfo throw IllegalArgumentException on the Boolean payload. Behavior change: getObject on the four columns now returns Boolean (per JDBC spec), not String. Callers that previously cast (String) rs.getObject(...) will get a ClassCastException; rs.getBoolean(...) starts working where it previously threw on the VARCHAR path, and rs.getString(...) keeps returning the same lowercase "true"/"false" via BooleanVectorAccessor.getString. Pin the schema with three new MetadataSchemasTest methods mirroring the existing COLUMNS coverage (names / typeNames / JdbcTypeIds), add a strict- type regression test for VarCharVectorSetter modeled on IntegerVectorSetterRangeCheckTest so a future re-widening trips CI, and exercise rs.getBoolean on the four boolean columns end-to-end in DataCloudDatabaseMetadataTest.testGetTypeInfo.

ArrowStreamReaderCursor.close used a plain try/finally that closed reader first, allocator second. When both threw — the most likely failure mode because the allocator's leak detector fires on close when buffers are still outstanding, which is exactly what an exception during reader.close produces — Java's finally semantics replaced the reader's exception with the allocator's. The reader exception is the diagnostically interesting one (the leak detector firing on allocator.close is usually a symptom); silently dropping it left only the symptom in the stack trace. Switch the cursor to try-with-resources over the (allocator, reader) pair so reader closes first and the allocator's exception attaches as suppressed onto the reader's instead of replacing it. Same fix on the construction-failure cleanup in DataCloudResultSet.of: the reader.close was already wrapped with addSuppressed but the immediately-following allocator.close was bare and could replace the original construction SQLException; wrap it the same way. Pin the new behavior with a Mockito-based test that throws from both reader.close and allocator.close and asserts the reader's exception is primary with the allocator's attached as suppressed.

DataCloudStatement.executeQuery and getResultSet both fetched iterator.getQueryStatus().getQueryId() twice — once when constructing arrowStream and once when calling DataCloudResultSet.of with it. The second call sat between arrowStream creation (which puts a 100 MB RootAllocator on the field) and the of(...) call that takes ownership of that allocator. If the second getQueryId() throws — e.g. a future refactor makes getQueryStatus async, or a transient gRPC failure surfaces through the cached proto — the allocator escapes both DataCloudResultSet.of's own try/catch (never entered) and the surrounding catch (StatusRuntimeException) (which doesn't close arrowStream). The PR explicitly claims every code path closes its allocator; this hoist closes the window without changing any observable behavior.

…fy cap Both Result-holder construction sites — QueryResultArrowStream.toArrowStreamReader and MetadataResultSets.of — built the RootAllocator first and then handed it to a new ArrowStreamReader. If the reader's constructor throws (today benign, but a future Arrow upgrade could add constructor-side validation), the allocator escapes both DataCloudResultSet.of's own try/catch (never entered) and the caller's catch. Wrap the construction in try/catch that closes the allocator on the way out and attaches any close failure as suppressed. Unify the per-allocator cap: MetadataResultSets used Long.MAX_VALUE while the gRPC path was capped at 100 MB. The cap exists because Arrow allocators are accounted memory, so hitting the cap throws a clean OutOfMemoryException instead of letting the JVM OOM. A getColumns(...) against a tenant with thousands of tables silently bypassed the cap on the metadata path. Promote the constant to public ROOT_ALLOCATOR_BUDGET_BYTES on QueryResultArrowStream and reuse it from MetadataResultSets. No new test: the failure mode requires ArrowStreamReader's constructor to throw, which doesn't happen with ByteArrayInputStream or the gRPC channel today. Pure code-shape fix; existing suite stays green.

JDBC 4.2 Table B-6 lists INTEGER → boolean as a recommended conversion: 0 maps to false, non-zero maps to true. pgjdbc and other major drivers do this. BaseIntVectorAccessor inherited the abstract default from QueryJDBCAccessor, which throws SQLFeatureNotSupportedException — so rs.getBoolean("NULLABLE") on a metadata int column failed where every spec-respecting client expects it to work. Add the override (one line, getLong() != 0). Restore the assertThat(getBoolean("NULLABLE")).isFalse() assertion that was deleted in the metadata-unify rebase, add a positive case for ORDINAL_POSITION, and correct the comment that previously claimed the coercion already happened. This is the second half of the JDBC-spec compliance pair started in 4c52910 (TYPE_INFO boolean columns are now declared as BIT, so VARCHAR → boolean isn't needed there). After this commit, every metadata int column that BI tools read as boolean (NULLABLE, columnNoNulls/columnNullable values, ORDINAL_POSITION) returns the spec-correct coercion.

…lures DataCloudResultSet.close set the closed flag *after* delegating to cursor.close. If cursor.close threw — e.g. allocator's leak detector trips an IllegalStateException, or the addSuppressed chain surfaces a reader exception — the flag stayed false. A defensive caller that catches the close failure and retries (JDBC connection pools and driver wrappers sometimes do) re-entered cursor.close, calling allocator.close on an already-closed RootAllocator. Arrow throws on second close. Flip the flag before delegating, matching the standard JDK AutoCloseable idempotence pattern. The caller still gets the cleanup exception on the first close; subsequent closes become no-ops. Pin the new contract with a Mockito-based test that throws from allocator.close on first cursor.close and asserts the second close is a no-op (allocator.close called exactly once across both attempts).

DecimalVectorSetter.setValueInternal called value.unscaledValue().longValue() unconditionally. BigInteger.longValue() silently truncates to the low 64 bits when the magnitude exceeds Long.MAX_VALUE — a BigDecimal("1E40") wrote garbage and the caller had no way to know. The integer setters in this same file already throw IllegalArgumentException for analogous out-of-range narrowing (lines 240, 261, 433); decimal was the asymmetry. Add the same guard via BigInteger.bitLength() > 63: catches both directions of overflow and throws IllegalArgumentException with the unscaled value in the message. Pin the new behavior with three tests mirroring the integer-setter range-check style — accepts values within long range, rejects above, rejects below. The separate scale-mismatch issue (DecimalVectorSetter ignores the vector's declared scale and writes whatever scale the caller's BigDecimal happens to have) is out of scope for this finding.

closesReaderAndAllocator only counted invocations on reader.close and allocator.close — a regression that flipped the order would slip past CI. Add an InOrder assertion so the load-bearing ordering documented on ArrowStreamReaderCursor.close (reader first, then allocator, so the allocator's closing budget check sees no outstanding ArrowBufs) is explicit at the test level rather than inferred indirectly from the throw-during-close test's primary/suppressed invariant.

The driver carried an Arrow field-metadata key (`datacloud-jdbc:type_name`), a `ColumnMetadata.typeName` field, four `Constants` tag strings, and a `bool(...)` schema helper to override `ResultSetMetaData.getColumnTypeName(int)` with Hyper-flavored labels — `"TEXT"` instead of `"VARCHAR"`, `"SHORT"` instead of `"SMALLINT"`, `"BOOL"` instead of `"BOOLEAN"`, `"INTEGER"` instead of `"INTEGER"` (no-op). Worth checking whether this was actually buying anything. JDBC 4.2 spec on `getColumnTypeName`: "Retrieves the database-specific type name for the designated column." No specific strings required. pgjdbc returns lowercase Postgres-native names (`text`, `int4`, `bool`, `varchar`, `bpchar`, `numeric`). The driver's own JDBCReferenceTest already normalizes both forms by mapping pgjdbc's `TEXT` to `JDBCType.VARCHAR.getName()` and `BPCHAR` to `JDBCType.CHAR.getName()` before comparison — so even internally the JDBC names are the canonical form. Spark `TypeMapping.scala` branches only on the int `getColumnType` code, never on the type-name string. Drop the override channel entirely. `getColumnTypeName` now returns `HyperTypes.toJdbcTypeName(col.getType())` for every column. Every metadata result-set column reports its JDBC-spec name. Removes ~125 lines of plumbing across `HyperTypeToArrow` (the metadata key write path), `ArrowToHyperTypeMapper` (read path), `ColumnMetadata` (the `typeName` field and 3-arg constructor), `MetadataSchemas` (the third arg on every helper), `Constants` (TEXT/INTEGER/SHORT/BOOL fields), `DataCloudResultSetMetaData.getColumnTypeName` (the override-or-fallback dispatch), and `MetadataResultSets.writeArrowStream` (the only stamp site). Test updates: `ArrowToHyperTypeMapperTest` deleted (it pinned the override read path); 63 assertions in `DataCloudDatabaseMetadataTest` flipped from `"TEXT"` / `"SHORT"` to `"VARCHAR"` / `"SMALLINT"` (the JDBC defaults); `MetadataSchemasTest` re-pins the four BOOLEAN positions in TYPE_INFO at `"BOOLEAN"` / `Types.BOOLEAN`. Behavior on `getColumnType` (the int code), `Types.BOOLEAN` for boolean metadata columns, accessor coercion — all unchanged.

The previous implementation returned `getLong() != 0`, silently coercing any non-zero integer (2, -1, MAX_VALUE) to `true`. ResultSet.getBoolean's own Javadoc only defines the conversion for exactly 0 and 1 — the spec is silent on other values. pgjdbc throws CANNOT_COERCE on anything else (BooleanTypeUtil.fromNumber). Match that strict behavior: 0 → false, 1 → true, anything else throws SQLException with SQLState 22018. The "non-zero → true" extrapolation was the same flavor of silent coercion the rest of this PR sets out to remove (VarCharVectorSetter accepting arbitrary Object via toString, integer setters silently truncating out-of-range Numbers). Catching here too rather than letting a real integer column lose its value when bounced through getBoolean. Update the metadata-test assertion: ORDINAL_POSITION = 500 used to coerce to true under the permissive path; now asserts the SQLException with the expected message.

mkaufmann commented Apr 24, 2026

View reviewed changes

Comment thread jdbc-core/src/main/java/com/salesforce/datacloud/jdbc/core/metadata/MetadataArrowBuilder.java Outdated

Comment thread jdbc-core/src/main/java/com/salesforce/datacloud/jdbc/core/ArrowStreamReaderCursor.java Outdated

mkaufmann commented Apr 24, 2026

View reviewed changes

Comment thread jdbc-core/src/main/java/com/salesforce/datacloud/jdbc/core/StreamingResultSet.java Outdated

mkaufmann force-pushed the moritz/centralize-types-via-hypertype branch 2 times, most recently from 9ecba8a to 08d62bc Compare May 7, 2026 19:10

Base automatically changed from moritz/centralize-types-via-hypertype to main May 7, 2026 19:25

mkaufmann force-pushed the moritz/unify-result-sets branch from b648940 to 07125b1 Compare May 11, 2026 13:38

mkaufmann commented May 11, 2026

View reviewed changes

mkaufmann force-pushed the moritz/unify-result-sets branch from 07125b1 to e329860 Compare May 11, 2026 15:02

mkaufmann force-pushed the moritz/unify-result-sets branch from e329860 to d17f1b0 Compare May 11, 2026 16:20

This was referenced May 11, 2026

chore: skip zero-row batches in ArrowStreamReaderCursor #185

Merged

fix: support getObject(Class) with identity class type in QueryJDBCAccessor #186

Merged

mkaufmann force-pushed the moritz/unify-result-sets branch from d17f1b0 to f4cad29 Compare May 11, 2026 17:16

mkaufmann force-pushed the moritz/unify-result-sets branch 2 times, most recently from 67ddd24 to b97abe2 Compare May 11, 2026 18:37

mkaufmann added 13 commits May 15, 2026 12:14

mkaufmann force-pushed the moritz/unify-result-sets branch from b83e8b7 to 7baf67d Compare May 15, 2026 10:19

mkaufmann changed the title ~~refactor: unify ResultSet implementations on Arrow-backed path~~ refactor!: unify ResultSet implementations on Arrow-backed path May 15, 2026

mkaufmann added 8 commits May 15, 2026 16:34

mkaufmann marked this pull request as ready for review May 18, 2026 07:30

mkaufmann changed the title ~~refactor!: unify ResultSet implementations on Arrow-backed path~~ refactor: unify ResultSet implementations on Arrow-backed path May 18, 2026

mkaufmann added 2 commits May 18, 2026 12:43

praveen2450 approved these changes May 18, 2026

View reviewed changes

KaviarasuSakthivadivel approved these changes May 18, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

refactor: unify ResultSet implementations on Arrow-backed path#175

refactor: unify ResultSet implementations on Arrow-backed path#175
mkaufmann wants to merge 24 commits into
mainfrom
moritz/unify-result-sets

mkaufmann commented Apr 24, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

codecov Bot commented May 11, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mkaufmann commented May 11, 2026

Uh oh!

mkaufmann commented May 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

mkaufmann commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

What changed

Observable behavior changes

Breaking changes

Test plan

Uh oh!

Uh oh!

Uh oh!

Uh oh!

codecov Bot commented May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mkaufmann commented May 11, 2026

Uh oh!

mkaufmann commented May 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mkaufmann commented Apr 24, 2026 •

edited

Loading

codecov Bot commented May 11, 2026 •

edited

Loading