Apache Ignite 2

Thin JDBC: соединение, prepared statements, result sets, bulk load и ODBC escapes

Публичные свойства продукта, восстановленные по тестовым свидетельствам.

Thin JDBC: соединение, prepared statements, result sets, bulk load и ODBC escapes

Эта страница — публичная реконструкция продуктовой спецификации по исходникам тестов Apache Ignite 2 на ревизии 486a6367610c4c891b729e89373695ef83165345.

Тесты Thin JDBC описывают поверхность connection API, bind prepared statements, чтение result sets, CSV bulk loading и переписывание ODBC escape-последовательностей.

Пользовательские гарантии

Трассируемые требования

После имени теста указывается только негативный или неоднозначный статус, например status=failed, status=flaky, status=ignored или status=mixed.

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

Требование: Thin JDBC должен принимать default/canonical connection settings, отвергают invalid endpoints, map поддержанные URL properties, и раскрывают statement/prepared-statement factory behavior включая неподдержанный overloads.

Зачем это нужно: Приложения нужны предсказуемый connection setup и clear неподдержанный-feature boundaries.

Граница: Weaker где доказательства depends on Java assert or точные неподдержанный-feature диагностика.

Тесты-доказательства:

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

Требование: The thin JDBC connection implements standard Connection surface behavior для 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, и concurrent access errors.

Зачем это нужно: JDBC-клиентам нужны предсказуемый standards-compatible behavior и clear неподдержанный-feature ошибки.

Граница: Evidence: many checks являются narrow API-surface or неподдержанный-feature assertions.

Тесты-доказательства:

JDBC-BULK-LOAD-CSV-01 — поведение COPY FROM CSV import

Требование: COPY FROM ... FORMAT CSV должен import CSV data, возвращают row counts, поддерживают выбранные null/trim/delimiter/charset/packet-size modes, и work для created/configured tables включая non-affinity-node routing.

Зачем это нужно: Bulk loading является operator/application ingestion path и должен обрабатывать ordinary CSV variations predictably.

Граница: Свидетельство из small local files; не throughput, rollback, or distributed ошибка-recovery guarantee.

Тесты-доказательства:

JDBC-BULK-LOAD-ERRORS-01 — bulk-load errors возвращаются через JDBC execution surface

Требование: Bulk load должен отвергать некорректный CSV quoting, bad charset/file/table/column/type inputs, и неподдержанный execute/query/prepared-statement surfaces с JDBC-visible ошибки.

Зачем это нужно: Пользователям нужны bad imports чтобы fail explicitly rather than silently loading corrupt data.

Граница: Weaker для точные диагностический и неподдержанный-surface behavior.

Тесты-доказательства:

JDBC-PREPARED-STMT-01 — prepared statements bind поддержанные values и отвергают неподдержанный inputs

Требование: Prepared statements должны сохранять parameters across executions, поддерживать custom objects и keep-binary paths где enabled, bind scalar/temporal/binary/blob/clob/stream/null values, и отвергают неподдержанный setters/types.

Зачем это нужно: Приложения полагаются на typed parameter binding и clear ошибка для неподдержанный JDBC features.

Граница: Weaker где stream/blob exception paths or неподдержанный types являются exact-surface checks.

Тесты-доказательства:

JDBC-RESULT-SET-01 — result sets раскрывают values, navigation, lookup и closed-resource behavior

Требование: Result sets должен раскрывать scalar, decimal, binary/blob/clob/stream, temporal, object/binary-object values, navigation, column lookup, неподдержанный update/type APIs, и closed-resource ошибки.

Зачем это нужно: JDBC-потребителям нужны стабильный readback behavior и предсказуемый resource/неподдержанный-feature boundaries.

Граница: Weaker где доказательства являются неподдержанный API or closed-resource диагностика.

Тесты-доказательства:

ODBC-ESCAPE-REWRITE-01 — ODBC escape sequences являются rewritten or rejected deterministically

Требование: ODBC escape parsing должен rewrite поддержанные function, convert, GUID/date/time/timestamp, outer join, procedure-call, и LIKE escape forms при этом preserving literal text и rejecting некорректный sequences.

Зачем это нужно: ODBC/JDBC compatibility depends on предсказуемый parser rewriting до SQL execution.

Граница: Parser tests доказывают rewriting, не execution semantics of the resulting SQL.

Тесты-доказательства:

Важные границы