Datum definitions

The Datum trait holds much of the core serialization/deserialization logic that powers entity storage. While generally you will not need to implement Datum yourself for any types, this chapter provides an overview of how the various datum-related traits interact. Most interfaces only require a Datum type, but some will also use the subtraits OwnedDatum ('static + Clone datums) and BorrowedDatum (Copy datums). In particular, all fields of a type that derives Entity must satisfy an OwnedDatum constraint.

There are three manners in which Datum types are used in the microrm API:

1. Returned from queries with static lifetime,
2. Returned from queries with local lifetime,
3. Passed to queries for updates/inserts.

All Datum types can be used in the third manner, but only some can be used in the first or second. The following table describes which lifetimes the types that microrm supports out of the box support, where S is a type satisfying the bound serde::Serialize + serde::DeserializeOwned and T is a type satisfying the bound Datum:

Note that isize and usize explicitly do not have Datum implementations, because their size is platform-dependent: writing to a database on a 64-bit system and then reading it on a 32-bit system could produce incorrect results.

OwnedDatum and BorrowedDatum

Briefly, OwnedDatum is a Datum that has a 'static lifetime, i.e. it owns its data, and BorrowedDatum is one that has a non-'static lifetime. The relationship is slightly more complicated than just that, however: each OwnedDatum is required to define a BorrowedDatum that acts as its ‘canonical’ reference type, and each BorrowedDatum defines what OwnedDatum it represents. There may be multiple such BorrowedDatum types for a single OwnedDatum; consider for example &[u8] and &Vec<u8> as borrowed versions of Vec<u8>.

1. For types that are inherently Copy, the associated reference type is exactly the same as the owned type. ↩ ↩2 ↩3 ↩4

2. Requires the serialized feature. ↩ ↩2

3. Requires the time feature. ↩ ↩2