SQLite's ALTER TABLE functionality leaves a lot to be desired, so
in practice the way you alter SQLite schema is to create a new
table, migrate the data into it, then drop the old table. However,
this is potentially complicated by the presence of foreign key
constraints.
In order to resolve the foreign key constraint issue we add a
`maintenance()` method to the `DataSource` abstraction layer. This
operates similarly to the existing `transaction()` method, but the
SQLite implementation of this method defers enforcement of foreign
keys until the transaction is about to commit.
They don't by default, because they didn't in older versions of
SQLite and some older applications might rely on that. You have to
send an explicit pragma prior to opening a transaction to make them
take effect.
We'll keep the door open for side-by-side support of Postgres in
the background, but due to SQLite's type system quirks we cannot
use the same DDL for both databases, so we would have to maintain
two sets of DDL (schema init and schema migration scripts) at once.
Interested future contributors can shoulder this maintenance burden
if they so choose.
Everything is a scalar value now, and while this does involve more
boilerplate it will also catch type conversion issues like
"1" + 0 === "10" in the future.
