Squashed migrations

[jukkah]

Is there any way to combine migrations to squashed migrations and run them instead of the original migrations? Currently no, I guess.

As you know, if there is a zillion of migrations, running them all from the beginning to the end may take a while. In addition, if you have [email protected] and you upgrade it to [email protected], performance of the database migration matters.

For example, Django have some kind of implementation for squashed migrations. I'm not sure if Django replaces migrations with squashed ones, but I think it's better to save them just in case. So there should be all the migrations plus some squashed migrations.

In the picture above, black dots are migrations created between releases. Bellow the migrations are squashed migrations. In this example, there are squashes for each minor and major release and one from the beginning to the latest release.

I think, in umzug, we need only

• a list of migrations combined into each squashed migration,
• a way to figure out what squash to use if any, and
• a way to make difference between migrations and squashes.

I can implement this feature but it needs some discussion first.

[sdepold]

How would this mechanism be applied? Is that a runtime feature that is executed when running up or down or is it an extra command that squashes the existing migrations?

[jukkah]

This would be a runtime feature. Because we don't care about implementations of up and down functions, we don't need to analyze them to figure out how to squash them. If some other libraries can create migrations they should also squash them.

My vision of squash file is to follow syntax of migration file:

'use strict';

var Bluebird = require('bluebird');

module.exports = {
  // List of migrations squashed in this squash file.
  migrations: ['some-id', 'some-other-id'],

  up: function () {
    return new Bluebird(function (resolve, reject) {
      // Describe how to achieve the task.
      // Call resolve/reject at some point.
    });
  },

  down: function () {
    return new Bluebird(function (resolve, reject) {
      // Describe how to revert the task.
      // Call resolve/reject at some point.
    });
  }
};

When running up and down we (un)log each of listed migrations.

These files should be stored in squashes sub-directory or something like that. Another way is to use file names not starting with number. This allows us to require them all at the beginning and then figure out the "best way".

[sdepold]

tbh I don't see a major benefit unless we are also implementing this:

then running an optimizer over them to try and reduce the length of the list - for example, it knows that CreateModel and DeleteModel cancel each other out, and it knows that AddField can be rolled into CreateModel.

are you planning to do this too? or are we just talking about the amount of migrations being executed?

[jukkah]

Yeah, of course, you got the point. 👍

[sdepold]

Alright. The interesting part is that umzug is a framework agnostic tool which you may or may not use with Sequelize. While I don't mind have a good portion of sequelize specific helpers in umzug please keep in mind that umzug is can also be used without sequelize and with any available sequelize versions out there.

[papb]

tbh I don't see a major benefit unless we are also implementing this:

then running an optimizer over them to try and reduce the length of the list - for example, it knows that CreateModel and DeleteModel cancel each other out, and it knows that AddField can be rolled into CreateModel.

are you planning to do this too? or are we just talking about the amount of migrations being executed?

I agree, without this there wouldn't be an advantage. And this would clash with umzug being framework agnostic.

I will close as wontfix. Maybe this can be implemented in the Sequelize CLI at some point. But I also think this is too complex to be worth it right now 😅