liter/meta.rs
1//! Various meta-programming traits for [`Schema`](crate::Schema) validation
2//!
3//! None of the traits in this module should be implemented manually, and many are sealed.
4//! 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).
5//!
6//! Here's an example of this type of error being spotted.
7//!```compile_fail
8//! use liter::{database, Ref, Table};
9//!
10//! /// This struct is not in `ExampleDB`
11//! #[derive(Table)]
12//! struct A {
13//! #[key]
14//! id: i64,
15//! version: u8,
16//! data: String
17//! }
18//!
19//! /// This one is, but references the struct that isn't
20//! #[derive(Table)]
21//! struct B {
22//! #[key]
23//! id: i64,
24//! reference_to_a: Ref<A>
25//! }
26//!
27//! #[database] // ← This fails because `B` requires that `A` is in the DB
28//! struct ExampleDB (
29//! B
30//! );
31//! ```
32//!
33//! 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.
34//! Only when we try to define an invalid database does the issue arise.
35
36/// Strip `()`s from nested tuple types
37pub mod filter;
38pub use filter::Filtered;
39/// A trait to specify a type that is either a plain `T` or a tuple `(A, B, …)` with many caveats
40pub mod tuple;
41pub use tuple::Tuple;
42/// [`Schema`](crate::Schema) validation
43pub mod validate;
44pub use validate::{
45 IsValidFor,
46 PartOf
47};