No way to tell which order migrations were applied in or when they were applied

[dseevr]

Hi,

Thanks for making this library.

Because there is no auto-incrementing primary key column and there is no column tracking when migrations were applied, there is no way to tell which order the migrations were applied in.

How do you feel about adding an applied column similar to Django?

mysql> show full columns from django_migrations;
+---------+--------------+--------------------+------+-----+---------+----------------+---------------------------------+---------+
| Field   | Type         | Collation          | Null | Key | Default | Extra          | Privileges                      | Comment |
+---------+--------------+--------------------+------+-----+---------+----------------+---------------------------------+---------+
| id      | int(11)      | NULL               | NO   | PRI | NULL    | auto_increment | select,insert,update,references |         |
| app     | varchar(255) | utf8mb4_unicode_ci | NO   |     | NULL    |                | select,insert,update,references |         |
| name    | varchar(255) | utf8mb4_unicode_ci | NO   |     | NULL    |                | select,insert,update,references |         |
| applied | datetime(6)  | NULL               | NO   |     | NULL    |                | select,insert,update,references |         |
+---------+--------------+--------------------+------+-----+---------+----------------+---------------------------------+---------+
4 rows in set (0.01 sec)

If you have no objections, I can add this + tests.

[andreynering]

Hi again @dseevr,

The idea of the column is good. I think I have to consider it, something similar was asked before as part of #4.

I'd be happy to review a patch for this.

Some things to keep in mind:

• I would not like to break anything in the version 1. It's too easy to break things adding columns, specially to critical stuff like database migrations. Conclusion: this will require releasing a new version (version 2);
• It would be nice to have a migration guide from version 1 to version 2. This requires some thought:
  • Should we create these columns as nullable? Should we ask users to update these columns with default data?
  • Should we change configuration to be more flexible about having custom columns?
• Since we're going to release a new version, I'll likely change the API a bit to make it a bit easier to use.

[niondir]

Looking forward for this. I agree that a migration from v1 to v2 must be possible. Maybe we can introduce one entry to the migration for this lib as well, to automate this.

I think an id and applied column would be very helpful. Further features could than be:

• RollbackN(5)
• RollbackToDate(date)

Maybe it's also useful to have a column rollback that contains a date when a rollback was applied and is set to null when the patch is re-applied. This way we must not delete rows from the database on rollbacks and keep the original order when re-appling migrations.

Another suggestion is to add a description column to give the possibilities to document what an migration is doing beside the id.

Liquibase might also be a good reference, to decide on what could be needed to implement a quiet complete migration framework.

Said that I pretty much like this library already. With a little more effort it can get really powerful.

[xorcare]

I find this approach strange, because the table that stores the migration state will also store the log of their run, if I understand you correctly.

Maybe it's also useful to have a column rollback that contains a date when a rollback was applied and is set to null when the patch is re-applied. This way we must not delete rows from the database on rollbacks and keep the original order when re-appling migrations.

I would like to highlight a few points that I would like to see:

• sort migrations by serial id
• in one table can live migration of different applications that would be able to separate the migration of applications and test data
• the presence of a separate comment field to be able to look at the list to say what happened to the base
• use in gorm migration code instead of native sql
• migration date and time
• the method converts the old data structure into a new one with the ability to add your own parser ID
• Describe the migration interface so that you can make your migration structure

[avakarev]

I'm closing this issue as stale. gormigrate evolved a lot since 2018 and many points are not valid anymore. If there is anything to request, please let's discuss it in dedicated issue / discussion.