option t turns a set of fields encoded as t into a correspending set of nullable fields. The encoder will encode None as into a tuple of NULL values and the decoder will return None if all fields are NULL.
If the type t itself is option t' for some t', or contains nested tuples and options such that all field types are nested under an option type, then it would have been possible to decode an all-NULL segment of a row as Some x where x is a corresponding tuple-option-tree terminating in None values. The above paragraph resolves this ambiguity since it implies that the outermost option possible will be decoded as None.
A type holding no fields. This is used to pass no parameters and as the result for queries which does not return any rows. It can also be nested in tuples, in which case it will not contribute to the total number of fields.
val tup4 : 'at->'bt->'ct->'dt->('a * 'b * 'c * 'd)t
Creates a 4-tuple type.
val custom :
encode:('a->('b, string)result)->decode:('b->('a, string)result)->'bt->'at
custom ~encode ~decode rep creates a custom type represented by rep, where encode is used to encode parameters into rep and decode is used to decode result rows from rep.
Note. This should be considered experimental and may be revised or removed in a future version.
A float mapped to double precision or (best alternative) on the SQL side. Serialization may be lossy (e.g. base 10 may be used), so even if both sides support IEEE 754 double precision numbers, there may be discrepancies in the last digits of the binary representaton.
An absolute time with driver-dependent precision. This corresponds to an SQL timestamp with time zone or a suitable alternative where not available:
MariaDB has datetime which is similar to the SQL timestamp and timestamp which is similar to the SQL timestamp with time zone, but the driver does not make the distinction. Caqti sets the session time zone to UTC to avoid misinterpretation, since time values are passed in both directions without time zones. Values have microsecond precision, but you will need to specify the desired precision in the database schema to avoid truncation.
PostgreSQL supports this type and it's a good option to avoid any time zone issues if used conistently both on the client side, in SQL expressions, and in the database schema. Note that timestamp with
time zone is stored as UTC without time zone, taking up no more space then timestamp. The PostgreSQL timestamp type is problematic since how conversions work and the manual indicate that it is meant to be a local time, and since database columns of this type stores the value without conversion to UTC, it becomes prone to time zone changes. To mitigate the issue, Caqti sets the time zone of sessions to UTC.
Sqlite3 does not have a dedicated type for absolute time. The date and time is sent as strings expressed at the UTC time zone using same format that the SQLite datetime function and CURRENT_TIMESTAMP return, except for an additional three decimals to achive millisecond precision.
It might seem better to use standard RFC3339 format, since it is accepted by the SQLite functions, but that would misorder some time values if mixed with the results of these functions, even just the "Z" suffix would misorder values with different precision.
Date and time values which comes from the database without time zone are interpreted as UTC. This is not necessarily correct, and it is highly recommended to use SQL types which are transmitted with time zone information, even if this is UTC.
A period of time. If the database lacks a dedicated representation, the integer number of seconds is used.
val enum :
encode:('a-> string)->decode:(string ->('a, string)result)->string ->'at
enum ~encode ~decode name creates an enum type which on the SQL side is named name, with cases which are converted with encode and decode functions. This is implemented in terms of the Caqti_type.Enum field type.