The shape of the program database.
The schema is deliberately boring and denormalised. It is written to be read
by something that gets one attempt at the query and cannot see the result of
a .schema call first, so every table carries the columns you would
otherwise have to join for. A call row knows the caller's module as well as
the full mfa string; a function row knows its module, name and arity as
well as the mfa that joins against everything else.
mfa strings are formatted as "MyApp.Accounts.create_user/2", and are the
join key throughout.
Summary
Functions
Column names for a table.
CREATE INDEX statements.
CREATE TABLE statements for every table.
A parameterised INSERT for a table, with one placeholder per column.
The table definitions as {name, [{column, type}]} pairs.
The schema rendered as DDL, for embedding in agent-facing documentation.
Functions
Column names for a table.
CREATE INDEX statements.
These are applied after the bulk load rather than before it. Maintaining sixteen indexes across a few million inserts costs considerably more than building them once over finished tables.
CREATE TABLE statements for every table.
A parameterised INSERT for a table, with one placeholder per column.
The table definitions as {name, [{column, type}]} pairs.
The schema rendered as DDL, for embedding in agent-facing documentation.