Replies: 3 comments 2 replies
-
Other thoughts: That will also help minimize the amount of extra information where people send their entire log file because they don't know what to look for (more is better than less, but I assume if there are migration failures, it will affect a lot of people and generate a lot of reports) |
Beta Was this translation helpful? Give feedback.
-
This looks good. I didn't think about how we would persist migrations for downwards migrations. Keeping them in I think the solution you proposed for handling errors in a migration is the most logical. We can make sure to have the migration failure logs be verbose like @nichwall mentioned. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the review and comments, they all make sense. I'll modify the design based on those.
The only slight change on your proposal, is that rather than performing migrations on a copy, I think it makes better sense to make a backup of the original before migrations, but perform the migrations on the original, since it has been already initialized by Database.connect(), and if the migrations succeeds (which they should most of the time), you can just continue to work on it. Only in case of a failure, you move the failed original to a saved version, and copy the backup over the original. |
Beta Was this translation helpful? Give feedback.
-
Objectives
We want to allow for safe and reversible ABS database migrations.
A user should be allowed to install arbitrary versions of ABS server on top of arbitrary database versions.
At server startup, if the server detects that the current server version changed, it should automatically attempt to migrate the database upwards or downwards to the closest migration:
Design
Some terminology:
version
field in the project'spackage.json
.settings
table. Let's call this the database_version.This design makes the following assumptions:
We plan to use umzug to run and keep track of migrations.
server/migrations
, and must follow the naming convention<server_version>-<migration_name>.js
(e.g.v2.13.0-unique_series.js
).up
anddown
, implementing the upwards and downwards migration scripts, as in the example below:Migrations will have a natural order determined by the order of their associated server versions.
In the new design, the server settings stored in the database will contain a new field,
max_version
. That field will hold the maximal server code ever userd with this database.At server startup, if a version change (
server_version != database_version
) occurred, the following will happen, afterDatabase.connect()
, and beforeDatabase.buildModels()
:server_version > max_version
(or if max_version doesn't exist)/config/migrations
max_version
to beserver_version
/config/migrations
server_version > database_version
migration_version <= server_version
(done by callingumzug.up({to: ...})
. Umzug adds to a special table on the database the names of executed migrations)server_version < database_version
migration_version > server_version
(done by callingumzug.down({to: ...})
. Umzug removes from a special table on the database the names of reverted migrations)database_version
to beserver_version
Questions
When downgrading the server (i.e.
server_version < database_version
), the code for some of downwards migration might not be available in the source tree (since it wasn't introduced yet for that version) - and Umzug doesn't save the downwards migration code in the database. Therefore the config directory always needs to have a version of the migrations that matches max_version. We probably also need to backup the migration scripts when we backup the database.This is an important question.
Beta Was this translation helpful? Give feedback.
All reactions