Osm Admin: Automated Migrations. Storing Migrated Schemas
1 month ago ∙ 1 minute read
More dots got connected in the schema migration design, see below.
Then, I tried to return to TDDing it, but strange errors met me there, so I left them to be resolved in the next piece.
- Automated Migrations
- How Current Schema Is Stored In DB
- Filesystem Stores Schema JSONs, Not PHP Files
Yesterday, I wrote:
For this reason, it's better to run migrations not on file change, but on page refresh in the browser (hitting
Well, it can be any HTTP route, any CLI command or any queued job that uses data from
$osm_app->schema is a cached property. In development, it's reloaded pretty often. Under
gulp watch it happens after any change in source code. In production, it's reloaded only during application update, or after running the
osm refresh command.
After schema is loaded, Osm Admin will check if it's still the same as of the latest migration in the database. If it's not, the application will fail in production, and it will run the migrations in development (if the
AUTO_SCHEMA_MIGRATIONS environment variable is set).
If several processes try to run automated schema migrations, only the first one runs, and then rest wait for it to finish (waiting for a lock to be released).
How Current Schema Is Stored In DB
Well, it seems that there is no need to store every applied schema, or every individual migration. It's enough to store the currently applied schema JSON.
And it's already implemented! It stored in the only row of the
schema table, in the
current column. More columns are yet to come, but this one has to stay.
Filesystem Stores Schema JSONs, Not PHP Files
In a similar fashion,
osm generate:schema saves the schema JSON from the codebase to