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
//! Various meta-programming traits for [`Schema`](crate::Schema) validation
//!
//! None of the traits in this module should be implemented manually, and many are sealed.
//! They exist to validate [`Schema`](crate::Schema)s at compile-time: making sure that types can only hold (foreign-key) [`Ref`](crate::Ref)erences to types that are in the same [`Schema`](crate::Schema).
//!
//! Here's an example of this type of error being spotted.
//!```compile_fail
//! use liter::{database, Ref, Table};
//!
//! /// This struct is not in `ExampleDB`
//! #[derive(Table)]
//! struct A {
//! #[key]
//! id: i64,
//! version: u8,
//! data: String
//! }
//!
//! /// This one is, but references the struct that isn't
//! #[derive(Table)]
//! struct B {
//! #[key]
//! id: i64,
//! reference_to_a: Ref<A>
//! }
//!
//! #[database] // ← This fails because `B` requires that `A` is in the DB
//! struct ExampleDB (
//! B
//! );
//! ```
//!
//! Note that it's not an error to define the structs `A` and `B` by themselves, since they don't know what [`Schema`](crate::Schema)s they will be a part of, `#[derive(Table)]` on `A` and `B` compiles just fine.
//! Only when we try to define an invalid database does the issue arise.
/// Strip `()`s from nested tuple types
pub use Filtered;
/// A trait to specify a type that is either a plain `T` or a tuple `(A, B, …)` with many caveats
pub use Tuple;
/// [`Schema`](crate::Schema) validation
pub use ;