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
//! Choices: closed-set enum field support.
//!
//! A user enum that implements [`ChoiceField`] can be used as a model
//! field type via `#[umbral(choices)]`. The framework stores the variant
//! as TEXT in the database; the Rust type system is the structural
//! constraint, with Postgres adding a `CHECK (col IN (...))` belt-and-
//! braces guard so a third-party process writing directly to the DB can't
//! insert a value the Rust enum can't model.
//!
//! Implementing the trait by hand is fine, but the common path is the
//! `#[derive(Choices)]` macro on a unit-variant enum:
//!
//! ```ignore
//! use umbral::prelude::*;
//!
//! #[derive(Debug, Clone, Copy, PartialEq, Eq, Choices)]
//! #[choices(rename_all = "lowercase")]
//! pub enum PostStatus {
//! Draft,
//! Review,
//! Published,
//! Archived,
//! }
//! ```
//!
//! The derive also emits the sqlx `Type` / `Encode` / `Decode` impls (for
//! Postgres and SQLite, both as `TEXT`), `Display`, and `FromStr` — so
//! the same enum value round-trips through the ORM, the admin form, and a
//! `Form` validator without any glue.
/// A field type whose values are drawn from a small, fixed set known at
/// compile time.
///
/// Implementors expose the value list (the strings stored in the
/// database) and matching human labels (used by the admin's `<select>`
/// widget). Position-for-position correspondence: `LABELS[i]` labels
/// `VALUES[i]`.
///
/// The trait is `Copy` so a `FieldSpec` referencing it stays usable in a
/// `const` slice — the same constraint we have on every other model
/// field type.