Version 1.0.0
Gateway database migrations
The migrations in the repository, in the order they apply, and the milestone to set on an existing database.
This page is generated from the files in gateway-db/migrations: it cannot describe a migration that does not exist, nor leave out one that does.
The 32 migrations
Section titled “The 32 migrations”They apply in the order of this table, which is the order of their numbers.
| Migration | What it does |
|---|---|
000-initial | baseline, the state before the first migration, defaults included |
001-endpoints | the endpoints table, an identifier on providers, and the endpoint in the request log |
002-endpoint-enabled | an endpoint can be disabled without being deleted |
003-model-table | the models table, to which endpoints attach |
004-plans | the plans table, and the plan an account belongs to |
005-convertion-rate | the conversion rates table |
006-plans-max-cost-euro | a plan’s cap is expressed in euros rather than credits |
007-plans-max-cost-euro-numeric | align the type of plans.max_cost_euro with init.sql |
008-provider-base-url-v1 | version the base URL of reference providers |
009-providers-slug-constraint-name | align the name of the uniqueness constraint on providers.slug |
010-retirer-les-cles-par-defaut | remove accounts holding an API key published in the repository |
011-plans-plafond-illimite | make a plan’s cap optional, and seed the administrator plan |
012-attributions-de-roles | move the assignment of the four roles in §5.3 to subjects |
013-journal-des-decisions-et-sessions | the authorization decision log, and identity sessions |
014-politiques-d-autorisation | move the authorization policy held by the server |
015-hacher-les-cles-api | stop storing API keys, only their digest |
016-revocation-des-sujets | the subject revocation list |
017-journal-des-actes-d-administration | the administrative acts log |
018-retirer-les-fournisseurs-semes | remove the two inference providers seeded by default |
019-installation-de-politique-journalisee | installing a policy becomes a logged administrative act |
020-annonce-de-l-execution-agentique | what the gateway announces about its agentic execution |
021-named-access-keys | an access key becomes an object, named and revocable on its own |
022-identifiant-de-ligne-de-facturation | each billing line carries the identifier of the relay that produced it |
023-roles-de-service-au-moindre-privilege | one PostgreSQL role per service, at least privilege |
024-organization-policy | the gateway becomes the emitter of an organization’s policy (#395) |
025-gateway-reads-authorization-decisions | the gateway may read the authorization journal, so the license module can rebuild its seat counter at startup |
025-politique-d-organisation-depuis-la-console | installing an organization policy becomes an administrative act with a proven author |
026-comptage-d-usage-dans-le-couloir-d-audit | the gateway counts what it relays, in the audit lane |
027-month-spend-index-on-request-logs | the month’s spend of one account, without reading the whole journal (#207) |
028-agent-acts | the acts of the agent, remitted by the workstations (first slice of #763) |
029-agent-acts-on-conflict-reads | the gateway reads agent_acts, because ON CONFLICT does (#763, first slice) |
030-agent-session-revocations | an administrator revokes one agent session |
The milestone to set on a database that already exists
Section titled “The milestone to set on a database that already exists”The migration script keeps a registry of applied migrations. A database created before that registry existed, or created directly by the installation file gateway-db/init.sql, does not have one: you have to tell it where it stands, otherwise the script would replay from the beginning.
That is what ./migrate.sh --baseline <numéro> does: it marks as applied every migration up to that number without running them.
For a database created by the installation file, the milestone is 030, the number of the last migration in this table. The installation file creates the full, up-to-date schema: replaying the migrations on it would fail, and setting a lower milestone would replay migrations already contained in the schema.
A milestone set too far produces no error: it marks as applied migrations that never were. On a real database, that leaves, for example, API keys in clear text in a database that the rest of the system believes converted. The milestone is not a guess: you read it in the table above.