teaql-runtime 0.7.5

TeaQL core, SQL, runtime, dialect, and macro crates for model-driven data access
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

# teaql-runtime

Minimal runtime repository and graph persistence layer for TeaQL Rust.

`teaql-runtime` owns TeaQL's runtime concepts: metadata lookup, repository
assembly, behaviors, checkers, events, graph planning, and in-memory execution.
Database execution is supplied by provider crates.

## What It Provides

- `UserContext` for metadata, typed resources, request locals, and runtime options
- repository registry and behavior registry
- memory repository for tests and lightweight execution
- checker registry and translated validation results
- entity event sink support
- graph save planning and execution
- typed entity graph extraction
- SQL debug logging options on `UserContext`

## Source Layout

The repository layer is split by concern under `src/repository/`:

- `types.rs`: public repository structs and relation load plan types
- `executor.rs`: `QueryExecutor` and graph transaction boundary types
- `cache.rs`: aggregation cache traits and in-memory cache
- `base.rs`: metadata-backed `Repository` compile and CRUD helpers
- `context.rs`: `UserContext` repository assembly and context repository logging/cache invalidation
- `resolved.rs`: entity-scoped repository query and mutation entry points
- `graph.rs`: graph planning, graph save execution, and graph node validation
- `relation.rs`: relation plans, relation enhancement, child queries, and relation aggregates
- `helpers.rs`: shared bucket keys, cache keys, projection helpers, and graph relation validation

## Example

```rust
use teaql_runtime::{InMemoryMetadataStore, UserContext};

let mut ctx = UserContext::new()
    .with_metadata(InMemoryMetadataStore::default());
ctx.enable_all_sql_log();

let logs = ctx.sql_logs();
assert!(logs.is_empty());
```

With generated code, applications typically register a generated runtime module
and then use generated entity/request helpers:

```rust
let ctx = UserContext::new()
    .with_module(my_domain::module())
    .with_repository_registry(my_domain::repository_registry());
```

Database, cache, message, search, AI, and filesystem integrations live outside
this crate as runtime providers/adapters. For SQLx-backed databases, choose one
database-specific provider crate:

```toml
teaql-runtime = "0.7"
teaql-provider-sqlx-postgres = "0.7"
teaql-provider-sqlx-sqlite = "0.7"
teaql-provider-sqlx-mysql = "0.7"
```

Provider crates expose a small registration helper. Runtime code registers
whichever provider the application selected, then calls the database-neutral
schema entry point:

```rust
use teaql_provider_sqlx_postgres::{PgMutationExecutor, PostgresProviderExt};
use teaql_runtime::{RuntimeError, UserContext};

let mut ctx = UserContext::new()
    .with_module(my_domain::module())
    .with_repository_registry(my_domain::repository_registry());

ctx.use_postgres_provider(PgMutationExecutor::new(pg_pool));
ctx.ensure_schema().await?;
```

The provider-specific helpers remain available for low-level use, but
application code should prefer `ctx.ensure_schema().await?` once a provider is
registered.

`teaql-runtime` itself no longer has a `sqlx` feature and no longer exports
`sqlx_support`.