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
//! The sqlx backend for keelson.
//!
//! One crate, three drivers behind features — `psql`, `mysql`, `sqlite`
//! — each exposing a `Pool` (and the transaction machinery via
//! [`keelson_exec::Begin`]) that implements [`keelson_exec::Executor`]. An
//! application constructs a pool here, in `main`, and everything above it —
//! generated models, hooks, plain query code — talks `keelson_exec` traits
//! and never names sqlx.
//!
//! Per-database drivers, not `sqlx::Any`: `Any` erases exactly what
//! `docs/type-mappings.md` requires kept (native `uuid`/temporal/decimal
//! parameter binds on the engines that have them).
//!
//! Each driver module owns two functions that make the type-mappings table
//! executable: `bind_value` (a total map `Value` → driver parameter, per the
//! "binds as" column) and `decode_value` (native row → `Value`, per the
//! column-type column). The round-trip suites in `tests/` are those two
//! functions' tests.
//!
//! # Where this sits
//!
//! The backend half of Layer 2: it implements
//! [keelson-exec](https://docs.rs/keelson-exec)'s traits and is the only crate in keelson
//! that links a database driver. Application code names it once, in `main`,
//! to build a pool; everything above talks `keelson_exec` traits. The
//! statements it runs come from a Layer 1 dialect ([keelson-psql](https://docs.rs/keelson-psql),
//! [keelson-mysql](https://docs.rs/keelson-mysql), [keelson-sqlite](https://docs.rs/keelson-sqlite)) or
//! from a generated model. The whole map is the [keelson](https://docs.rs/keelson) facade
//! crate.