◼ Apache Ignite Свойства продукта

Apache Ignite 2

SQL planning, constraints, control commands и discovery

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

SQL planning, constraints, control commands и discovery

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

Эти требования описывают проверенное поведение SQL planners, enforcement NOT NULL constraints, distributed SQL splitting, операторские контракты control commands и сходимость TCP discovery.

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

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

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

REQ-B4-CALCITE-MERGE-JOIN-PLANNER — Calcite planner выбирает merge join только для поддержанных equi/is-not-distinct join conditions

Требование: Calcite planner выбирает merge join только для поддержанных equi/is-not-distinct join conditions, выводит или сохраняет input collation для inner/right/left/full joins, избегает top sort, когда child ordering достаточен, и не использует merge join для non-equi joins.

Зачем это нужно: join planning должен использовать ordering без создания некорректных physical plans.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-CALCITE-SECONDARY-INDEX-FILTERS — Calcite SQL uses primary-key

Требование: Calcite SQL uses primary-key, affinity-key, secondary, date, и composite indexes для eligible equality/range/AND/OR filters и falls back чтобы table scans где fields являются не indexed or conditions являются не indexable, при этом preserving result rows.

Зачем это нужно: пользователи get предсказуемый indexed access без wrong answers.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-CALCITE-SECONDARY-INDEX-ORDER — Calcite SQL can satisfy ORDER BY и range-bound queries из suitable indexes

Требование: Calcite SQL can satisfy ORDER BY и range-bound queries из suitable indexes, avoid redundant sort/project nodes in eligible cases, merge overlapping index bounds, и keep корректный ordering/results для indexed и non-indexed order expressions.

Зачем это нужно: sorted/range queries должен быть эффективным и стабильный.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-CONTROL-CACHE-DIAGNOSTICS — control utility cache commands обнаруживают idle-verify conflicts

Требование: The control utility cache commands обнаруживают idle-verify conflicts, write/read dumps, filter caches/groups/nodes/system caches, scan cache entries in default/table/JSON formats с limits, show cache configuration/affinity/distribution, reset lost partitions, clear caches с confirmation, и сообщать о garbage absence.

Зачем это нужно: операторы нужны accurate cache inspection и repair tooling.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-CONTROL-CLUSTER-STATE-BASELINE — control utility reports и changes cluster state/tag/baseline/shutdown policy

Требование: The control utility reports и changes cluster state/tag/baseline/shutdown policy, transaction info, и connectivity диагностика с validated arguments, state transitions, и operator-visible output.

Зачем это нужно: операторы нужны reliable cluster lifecycle и диагностический commands.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-CONTROL-HELP-VERBOSE-EXPERIMENTAL — control utility help

Требование: The control utility help, cache help, offline command dispatch, timestamp footer, experimental-command gating, и verbose error handling раскрывают documented commands и stack traces according чтобы flags.

Зачем это нужно: операторы нужны discoverable и debuggable CLI behavior.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-CONTROL-SNAPSHOT-WAL-WARMUP — control utility snapshot

Требование: The control utility snapshot, WAL, и warm-up commands validate arguments, create/check/cancel/restore full и incremental snapshots включая custom directories и synchronous mode, surface warnings/errors, сообщать о status, restrict inactive-cluster operations, target unused WAL by node, и stop warm-up когда supported.

Зачем это нужно: persistence operations должны быть наблюдаемыми и recoverable из CLI.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-DISCOVERY-TCP-CLIENT — TCP client discovery поддерживает client join/leave/fail events

Требование: TCP client discovery поддерживает client join/leave/fail events, client/server pings, router failover/reconnect после suspend/network/topology changes, missed-message recovery, segmentation, metrics/data exchange, duplicate-ID и join-timeout errors, client worker startup, concurrent joins, disabled reconnect ошибка handling, forced reconnect, и стабильный grid start time.

Зачем это нужно: client nodes должен оставаться observable и recover из discovery disruptions без corrupting topology.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-DISCOVERY-TCP-SERVER — TCP server discovery поддерживает node start/stop

Требование: TCP server discovery поддерживает node start/stop, ping/ошибка detection, node add/leave/fail events, metrics propagation, IP finder cleanup/multicast validation, join timeout/duplicate/loopback errors, custom event races/coordinator ошибки, failed-node recovery, topology cleanup, marshaller-data filtering, discovery-data deduplication, ring latency checks, и unresolved-address filtering.

Зачем это нужно: server topology membership должен converge predictably при normal и ошибка conditions.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-H2-SUBQUERY-JOIN-OPT — H2 SQL subquery join optimization сохраняет query semantics при этом applying eligible rewrites для SELECT expressions

Требование: H2 SQL subquery join optimization сохраняет query semantics при этом applying eligible rewrites для SELECT expressions, table-list subqueries, EXISTS/IN/NOT IN predicates, aliases, constants, UNION branches, casts, CASE expressions, left joins с false predicates, и nested subqueries; неподдержанный aggregate/distinct/correlated shapes остаются unoptimized.

Зачем это нужно: пользователи get faster distributed SQL без changing query answers.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-SQL-NOT-NULL-CACHE-OPS — Not-null QueryEntity constraints являются enforced для cache API writes

Требование: Not-null QueryEntity constraints являются enforced для cache API writes, entry processor mutations, putAll/invokeAll, atomic/implicit operations, и explicit transactions, при этом delete/no-value mutations остаются allowed.

Зачем это нужно: data integrity должен hold regardless of the write API used.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-SQL-NOT-NULL-DML-DDL — SQL DDL may declare or add NOT NULL fields on поддержанные caches и SQL DML отвергает INSERT/UPDATE paths that would write

Требование: SQL DDL may declare or add NOT NULL fields on поддержанные caches и SQL DML отвергает INSERT/UPDATE paths that would write null into constrained fields; read-through и interceptor caches отвергают not-null query entities/create-table/alter-table constraints.

Зачем это нужно: SQL constraints должны применяться uniformly и only где Ignite can guarantee them.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-SQL-NOT-NULL-METADATA — QueryEntity stores not-null field metadata in getter/setter state и equality semantics

Требование: QueryEntity stores not-null field metadata in getter/setter state и equality semantics.

Зачем это нужно: cache/table definitions должен оставаться comparable и reproducible across configuration paths.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-SQL-SPLITTER-AGGREGATES-INDEXES — SQL aggregation

Требование: SQL aggregation, HAVING, AVG over numeric types, empty-cache aggregates, group-index bounds, index hints, и sorted merge index plans возвращают корректный results и раскрывают the expected plan markers.

Зачем это нужно: analytical SQL должен быть numerically корректный и planner choices должны быть наблюдаемыми.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-SQL-SPLITTER-DISTRIBUTED-JOINS — Distributed joins выбирают batched/unicast or colocated plans according чтобы partitioned/replicated cache placement

Требование: Distributed joins выбирают batched/unicast or colocated plans according чтобы partitioned/replicated cache placement, segmentation level, distributedJoins/enforceJoinOrder flags, и local query settings; incompatible segmentation fails instead of returning ambiguous results.

Зачем это нужно: mixed cache deployments нужны предсказуемый join correctness и operability.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

REQ-B4-SQL-SPLITTER-PAGING-PUSHDOWN — SQL splitter applies LIMIT/OFFSET

Требование: The SQL splitter applies LIMIT/OFFSET, subquery pushdown, schema name resolution, EXISTS/subquery joins, implicit join-condition generation, и function-expression queries consistently across distributed execution.

Зачем это нужно: пользователи expect distributed SQL чтобы возвращают the same rows as logical SQL при этом minimizing unnecessary reducer work.

Граница: Эти тесты доказывают только указанные fixtures и формы query/CLI/discovery; они не доказывают произвольную SQL-эквивалентность, каждый cache mode, каждый размер топологии, production timing или все interleavings ошибок за пределами проверенных сценариев.

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

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