Open msullivan opened 7 months ago
I've focused mostly on the compiler component, but there is also a lot of room for cleverness to make this truly in place. With appropriate setup, almost all of this can happen while the previous version is still running, and even serving write queries. (As long as no migrations are being done)
Other design notes (will edit):
Remaining TODOs:
Currently, while we allow in-place upgrades between minor versions, upgrading between major versions requires a dump and restore. This is slow, and requires downtime.
Currently we use the patch system to make catalog changes during minor version upgrades, but using the patch system for major versions is probably unworkable:
The plan then, is this:
edgedbstd
gets a version suffix, soedgedbstd_vX
edgedbstd
still exists, and will contain trampoline functions and views that point to the equivalent functions/tables in the namespaced schemaedgedbstd
.edgedbstd_vY
schema, and then update everything inedgedbstd
to point to it. (This probably means we can't ever remove fields from user visible tables, but that's probably OK.)edgedbstd_vX
database. Before the upgrade, we willDESCRIBE SCHEMA
the old database, along with all the schema object ids, (like dump does), and during the upgrade we will run that DDL script in order to populate the new reflection schema. (But we will not compile it to postgres, since the postgres tables already exist and are supposed to be compatible)Eventually we might need to actually change layout, in which case some major versions might not be upgradable. But also there's a good chance we could do it gradually, with some tables or functions or whatnot using the new layout and allowing gradual backfill migration.
Open questions (partial list):