Runtime Overview

TeaQL runtime execution starts after a generated API request is built. The runtime is responsible for turning business intent into storage operations while applying application policies.

Runtime Responsibilities

The runtime layer handles:

• Query execution
• Repository resolution
• Entity metadata lookup
• Transaction boundaries
• Validation and error translation
• Caching, logging, locking, and metrics hooks
• Database/provider-specific SQL or repository execution
• Graph loading, relation enhancement, aggregation, and graph writes

Java Runtime

The Java runtime is built around UserContext. Existing docs already describe this surface in detail:

• Understand UserContext
• Cache customization
• Logging customization
• Distributed locking
• Read/write requests
• Audit trail customization

Rust Runtime

The Rust runtime is designed around provider-backed repositories and generated business APIs.

Important Rust runtime concepts:

• teaql-core
• teaql-runtime
• teaql-sql
• teaql-macros
• RuntimeModule and module!
• Repository API
• Relation enhancement
• Relation aggregate enhancement
• Graph save
• Schema bootstrap
• MemoryRepository
• SQLx providers
• rusqlite provider

The first provider-focused page is Rust database providers.

Data Services

TeaQL models can declare data-service targets. Existing Java-oriented data-service docs are reused here because the concept is shared:

• KSML data service config

Execution Shape

Generated Q request
  -> Runtime context
  -> Repository API
  -> Provider implementation
  -> Database / Memory / Embedded storage

The goal is to keep the generated business API stable while allowing runtime providers to change underneath.