Spaces:
Running
Running
| # Browser SQLite/WASM order playground | |
| This executable example uses a familiar commerce domain—platform, customer, | |
| order, item, payment, and shipment—to demonstrate TeaQL queries entirely in a | |
| dedicated browser worker. It includes deterministic, internally consistent demo | |
| data and thirteen runnable examples organized as basic, aggregate, filtered, | |
| and dynamic queries. | |
| This page executes the TeaQL TypeScript runtime and SQLite/WASM directly in the | |
| browser. The model-driven Q and TraceChain contract is also implemented by the | |
| Java, Rust, Go, Python, .NET and Swift runtimes. The seven-language strip links | |
| to each runtime source and marks TypeScript as the current browser runtime; it | |
| does not imply that selecting another link swaps the page's execution engine. | |
| `OrderStatus` is a seventh, constant model object rather than a string field. | |
| Its five fixed values are reconciled through `RuntimeModule` bootstrap, orders | |
| store the status object ID, and generated Q expressions select, filter, and | |
| facet through the `status` relation. Visible status projections select `name` | |
| and `color`—not `code`—and the queried color drives the metric cards and status | |
| badges. Embedded relation Q expressions are displayed on one line so they align | |
| with the horizontal element they populate. | |
| The interface defaults to English and can be switched to Chinese without | |
| re-running the active query. Tabular results use a table by default and remain | |
| available as an expandable Result Tree instead of a raw JSON text block. | |
| Dynamic examples pass user-shaped filters through TeaQL's validated field | |
| metadata and do not use `eval`. | |
| The first example is a complete order management center. Its status metrics, | |
| search (including product-name subqueries), item previews, and pagination are | |
| all driven by one generated `Q.customerOrders()` expression. Application code | |
| uses the generated domain request API; the lower-level `SelectQuery` is confined | |
| to `src/generated`. Every example shows the exact Q expression used by the page | |
| and the parameterized SQL statements that SQLite executed, including timing, | |
| row counts, and policy-safe bindings. The execution evidence table prints the | |
| captured time, identity, intent, `tracePath`, and parameterized SQL on one row | |
| per statement. Each trace is plain text with arrows between its original path | |
| steps; no JSON metadata or decorative visualization is added, and no | |
| application tracing code is required. | |
| The order list labels its fourth column `Line Items`. Two seeded orders contain | |
| five internally consistent line items; the query still loads only three bounded | |
| previews and uses the separately queried item count to display `5 items`. | |
| The order-center Q expression is stable across free-text search, status-card | |
| selection, and pagination. Those interactions only replace `searchParams`, | |
| `pageOffset`, and `pageSize`; generated dynamic-search bindings compile order | |
| number, `OrderStatus.code`, and item product-name paths without changing the | |
| page query. | |
| The final page section retains an unmodified OpenObserve capture of the same | |
| Order-query lineage rendered as a business TraceChain. It connects the page | |
| purpose and nested request comments to the eight SQL executions captured by | |
| the observability backend; the screenshot is evidence, not a client-side | |
| reconstruction. | |
| The order-center projection intentionally contains only the four visible table | |
| columns: order number, order date, the `OrderStatus` object, and item preview. | |
| It does not load Platform or Customer. The Q chain follows the page vertically: | |
| dynamic filter, `countAs('totalOrders')`, status facet, four table projections, | |
| then bounded `offset` / `limit` list execution. | |
| ```bash | |
| npm install | |
| npm run dev | |
| ``` | |
| Memory storage is the deterministic default. Refreshing recreates the data. The | |
| optional OPFS mode persists within the current browser origin. Reset drops the | |
| browser-local schema, explicitly runs `context.ensureSchema()` again, and | |
| re-seeds the six mutable entities through governed, audited mutations; the five | |
| `OrderStatus` constants are restored by runtime bootstrap. | |
| The same application-approved mutation policy is used by both storage profiles. | |
| A denied plan is rejected before SQL is posted to the worker. | |
| The previous WorkItem example remains independently available at | |
| `/work-items.html`. The Vite development server emits the COOP/COEP headers required by the SQLite | |
| OPFS implementation. A production host must emit the same headers. This first | |
| profile intentionally excludes multi-tab database coordination and true row | |
| streaming. | |
| ## Generated order TraceChain page | |
| Open `/orders.html` to run the shared request-tree Order model in the same | |
| browser SQLite/WASM provider. The WorkItem page remains available at | |
| `/work-items.html`, while `/` presents the full order management center. | |
| `order-model.xml` defines the model; `orders-lib/` is generated by the local | |
| Model-Aware Services producer, not handwritten Q or entity code. Model-aware | |
| Assist outputs are retained under `assist/`. | |
| The order page uses generated audited mutation APIs to create four orders and | |
| five items per order. Generated bootstrap provisions the platform and three | |
| status constants. The example search matches three orders and loads the second | |
| one: KEEP-002, Paid, three item previews, and a full item count of five. Status | |
| facets retain counts and sums `(1,100)`, `(2,500)`, `(0,null)`. | |
| The textarea accepts runtime-validated search JSON, not executable JavaScript. | |
| The actual query is compiled application code using the generated Q API. The | |
| view reads selected fields through generated E expressions and displays data, | |
| page metadata and facets. Business TraceChain rendering uses only each actual | |
| statement's `traceChain`; `tracePath` is displayed separately. No SQL parsing, | |
| known-alias branches or UI-owned lineage is used. | |
| Diagnostic logging is on by default. Disabling it suppresses the diagnostic | |
| sink, while the explicitly installed evidence store still supplies the eight | |
| actual statements for the view. Memory refresh resets the data; OPFS survives | |
| refresh. Reset re-runs context-owned schema/bootstrap and generated mutations. | |
| ```bash | |
| npm run build | |
| npm run smoke | |
| npm run smoke:orders | |
| ``` | |
| The order smoke test runs real Chromium against the built deployment and | |
| checks memory/OPFS refresh/reset, both diagnostic modes, Q/E results, exact | |
| facet values, native operation comments, actual SQL count and unchanged | |
| generated-library hashes. The repository's `scripts/verify-examples.sh` runs | |
| both browser smoke tests. | |
| For maintainers with the generator checkout, regenerate the library and Assist: | |
| ```bash | |
| cd /path/to/teaql-code-gen | |
| TEAQL_TEST_TYPESCRIPT_RUNTIME_PATH=/path/to/teaql-ts \ | |
| mvn -q -pl generator -am \ | |
| -Dtest=PolyglotRequestTreeSqliteTest#sharedOrderFixtureExportsBrowserLibraryAndAssist \ | |
| -Dsurefire.failIfNoSpecifiedTests=false test | |
| ``` | |
| The generated library's local dependency points to this runtime repository. | |
| Do not manually repair `orders-lib/`; change the model or upstream templates | |
| and regenerate instead. | |