Skip to main content

252 Dynamic Queries Later: TeaQL's Six-Language Order Search Acceptance

· 3 min read
TeaQL Team
Core Team

On August 12 we published a persistence baseline across six TeaQL runtimes and a nine-database Java matrix. That was useful evidence, but it was not the complete Order Search Feature.

The next acceptance run closed that distinction. Java, Rust, Go, Python, .NET and TypeScript each executed the generated Order Search API against PostgreSQL, MySQL and SQLite: 18 of 18 core cells passed, representing 252 successful positive dynamic scenario executions.

What a complete core cell proved

Each language/database cell executed empty, root, parent, child, range, combined, empty-result and stable-pagination queries plus an exact per-parent Top-N. Rows, record count, SUM and grouped facets shared the same active filter and used database-native COUNT, SUM and GROUP BY.

Top-N evidence showed a partition/window plan rather than application overfetch. Preset saves were tenant-scoped, audited, idempotent and versioned; stale versions were rejected. Purpose, comment and audit-reason gates were exercised through the real generated APIs.

LanguagePostgreSQLMySQLSQLite
JavaPASSPASSPASS
RustPASSPASSPASS
GoPASSPASSPASS
PythonPASSPASSPASS
.NETPASSPASSPASS
TypeScriptPASSPASSPASS

Unknown fields, trusted-context override attempts, reversed ranges, wrong types, excessive IN/page size, deep paths, forbidden sorts and illegal offsets were rejected by the shared trusted endpoint validator before query construction. We report that boundary accurately rather than pretending each rejection was a language-specific SQL execution.

Governance was part of PASS

All six runtimes now expose two distinct mutation audit paths:

  1. a server-owned row or mutation audit path;
  2. a separately attributable application audit sink receiving metadata-masked events.

The 18 core cells passed both paths. Application feature logging was not accepted as a substitute for runtime audit infrastructure.

Extended databases moved beyond persistence-only

Java completed the full Feature on Oracle, DB2, DM8, SAP HANA, SQL Server and DuckDB. .NET completed the same Feature on SQL Server. These seven results cover stable pages, tenant isolation, exact Top-N, complete child counts, native aggregates, preset persistence, optimistic locking and governance—not only create/save/reconnect tests.

Snowflake remains BLOCKED_BY_ENVIRONMENT because the test environment lacks a complete account and authenticated user/context profile. A token alone was not treated as a connection profile, and no PASS was invented.

Federation used the real protocol

The generated TypeScript client sent its query through TeaQL's Federal Protocol /query endpoint. The Rust server routed it through teaql-tfp-endpoint to the PostgreSQL-backed generated runtime. Direct Rust and federated responses had identical canonical IDs.

Client attempts to override tenant, merchant, user, permissions, request policy, purpose policy and trusted context were rejected. A generic HTTP wrapper was not counted as federation.

The result is intentionally scoped: every executable core and extended cell passed, while global status remains a GAP until Snowflake has a complete external connection environment. Evidence is valuable only when its boundary is as precise as its green cells.