◼ Apache Ignite Product Properties

Apache Ignite 2

Thin JDBC

Public product properties reconstructed from test evidence.

Thin JDBC connection, prepared statements, result sets, bulk load and ODBC escapes

This page is a public product-spec reconstruction from Apache Ignite 2 test sources at revision 486a6367610c4c891b729e89373695ef83165345.

Thin JDBC tests describe the connection API surface, prepared-statement binding, result-set access, CSV bulk loading, and ODBC escape rewriting.

User-facing guarantees

Traceable requirements

Only negative or ambiguous test status is annotated after a test name, for example status=failed, status=flaky, status=ignored, or status=mixed.

JDBC-CONNECTION-URL-01 — connection URLs, properties and statement factories

Requirement: Thin JDBC must accept default/canonical connection settings, reject invalid endpoints, map supported URL properties, and expose statement/prepared-statement factory behavior including unsupported overloads.

Why: Applications need predictable connection setup and clear unsupported-feature boundaries.

Boundary: Weaker where evidence depends on Java assert or exact unsupported-feature diagnostics.

Evidence tests:

REQ-B4-JDBC-CONNECTION-API — standard Connection API surface

Requirement: The thin JDBC connection implements standard Connection surface behavior for nativeSQL, autocommit, commit/rollback limitations, metadata, read-only/catalog/schema/isolation/warnings/type-map/holdability/savepoint/client-info/Lob/SQLXML/array/struct/network-timeout/abort APIs, SSL mismatch errors, disabled feature flags, and concurrent access errors.

Why: JDBC clients need predictable standards-compatible behavior and clear unsupported-feature failures.

Boundary: Evidence: many checks are narrow API-surface or unsupported-feature assertions.

Evidence tests:

JDBC-BULK-LOAD-CSV-01 — COPY FROM CSV import behavior

Requirement: COPY FROM ... FORMAT CSV must import CSV data, return row counts, support selected null/trim/delimiter/charset/packet-size modes, and work for created/configured tables including non-affinity-node routing.

Why: Bulk loading is an operator/application ingestion path and must handle ordinary CSV variations predictably.

Boundary: Evidence from small local files; not a throughput, rollback, or distributed failure-recovery guarantee.

Evidence tests:

JDBC-BULK-LOAD-ERRORS-01 — bulk-load errors are reported through JDBC execution surface

Requirement: Bulk load must reject malformed CSV quoting, bad charset/file/table/column/type inputs, and unsupported execute/query/prepared-statement surfaces with JDBC-visible failures.

Why: Users need bad imports to fail explicitly rather than silently loading corrupt data.

Boundary: Weaker for exact diagnostic and unsupported-surface behavior.

Evidence tests:

JDBC-PREPARED-STMT-01 — prepared statements bind supported values and reject unsupported inputs

Requirement: Prepared statements must preserve parameters across executions, support custom objects and keep-binary paths where enabled, bind scalar/temporal/binary/blob/clob/stream/null values, and reject unsupported setters/types.

Why: Applications rely on typed parameter binding and clear failure for unsupported JDBC features.

Boundary: Weaker where stream/blob exception paths or unsupported types are exact-surface checks.

Evidence tests:

JDBC-RESULT-SET-01 — result sets expose values, navigation, lookup and closed-resource behavior

Requirement: Result sets must expose scalar, decimal, binary/blob/clob/stream, temporal, object/binary-object values, navigation, column lookup, unsupported update/type APIs, and closed-resource failures.

Why: JDBC consumers need stable readback behavior and predictable resource/unsupported-feature boundaries.

Boundary: Weaker where evidence is unsupported API or closed-resource diagnostics.

Evidence tests:

ODBC-ESCAPE-REWRITE-01 — ODBC escape sequences are rewritten or rejected deterministically

Requirement: ODBC escape parsing must rewrite supported function, convert, GUID/date/time/timestamp, outer join, procedure-call, and LIKE escape forms while preserving literal text and rejecting malformed sequences.

Why: ODBC/JDBC compatibility depends on predictable parser rewriting before SQL execution.

Boundary: Parser tests prove rewriting, not execution semantics of the resulting SQL.

Evidence tests:

Important boundaries