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
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
//! Internal helpers referenced by generated macro code.
//!
//! Implementation detail. The types in here are used by the code that
//! `oql!` expands to, not by user code directly. This module is
//! `#[doc(hidden)]` because the contract between the macro and its
//! helpers is internal: the macro is the public API, and the macro's
//! observable behaviour stays stable across versions regardless of how
//! this module evolves.
/// Sorts a `Vec<(K, T)>` by `K` in place and returns an iterator over the
/// stripped `T`s. Used by `orderby` expansion.
///
/// The generated code maps each element to a `(key, element)` pair,
/// collects into a `Vec`, and hands it here. We sort by comparing keys
/// directly (one comparison per pair, no re-cloning of keys during the
/// sort), then drop the keys and yield the elements.
///
/// Composite keys are plain tuples; Rust's `Ord` for tuples is
/// lexicographic, so earlier `orderby` clauses naturally take priority.
/// `desc` is encoded by wrapping the relevant key part in
/// `core::cmp::Reverse`.
///
/// Allocation budget per element: exactly one key clone (a no-op for
/// `Copy` types) and the vec itself. Sorting is `O(n log n)` comparisons,
/// `O(1)` extra memory; matching `sort_by_cached_key` on a plain
/// `Vec<T>`, but with the key expression written at the call site (so we
/// handle composite keys and `desc` without a typed closure signature).
/// Stack-allocated iterator for the 0/1/N match cases of a hash-join.
///
/// The hot path of a typical foreign-key join yields exactly one match
/// per outer element. Boxing a `dyn Iterator` for that case costs a heap
/// allocation per outer row, which dominates the macro's runtime on
/// join-heavy queries.
///
/// This enum holds all three outcomes inline:
///
/// * `Empty` ; no match; zero allocations.
/// * `Once(Some(x))`; exactly one match; zero allocations.
/// * `Many(vec)` ; two or more matches; one Vec allocation.
///
/// Dispatch happens through a regular `match`; because the enum is a
/// concrete type with known variants, the compiler inlines the
/// `Iterator::next` implementation end-to-end and the branch on the
/// variant tag fuses with the surrounding pipeline code.
/// The output of a `group by` clause.
///
/// `Group<K, T>` is what the `oql!` macro's `group by ... into g` produces
/// on every iteration: `g.key` is the grouping key, `g.items` is the vec
/// of elements that shared that key. Downstream clauses (`where`,
/// `orderby`, `select`) see the group, not the individual elements.
///
/// `items` is exposed as a `Vec<T>` on purpose, so the user can call any
/// `Iterator` method on `g.items.iter()` (`sum`, `count`, `max`, `fold`,
/// whatever). No dedicated aggregate keywords are baked in: Rust's
/// `Iterator` trait already covers every aggregate worth having.
///
/// Group ordering within the result is unspecified. Use `orderby` after
/// `group by` if you want deterministic iteration.