Breeze migration numbers mess with migration orders

[jwoertink]

If you're using breeze and you make a migration in your app, then run lucky db.rollback, the migration that gets rolled back is AddMoreDataToPipes::V10000000000003 and not the one that you just created.

You could use lucky db.rollback_to to get around it, but that will undo breeze data...

[jwoertink]

This issue is caused because your app requires all of the migrations before breeze. When a migration file is required (and thus the class inherited), the class is shoved in to an array

# sort of like this
macro inherited
  @@migrations = [] of MigrationClass.class
  @@migrations << {{ @type }}
end

The "fix" would be to require your app's migrations after breeze migrations get required. This causes other issues though because in development we check that your app is migrated when it boots.

Maybe we can sort this array when a new migration is added? https://github.com/luckyframework/avram/blob/master/src/avram/migrator/runner.cr#L11 This would allow us to push the breeze migrations to the bottom of the stack since their numbers are low. Maybe that's more expected anyway?

[wout]

Just ran into this issue too and rolling back to a timestamp works as expected.

I suppose ordering the array should do the trick?

[jwoertink]

That's what I was thinking. I'm not sure if that'll affect anything though 🤔

[wout]

I'm not sure if that'll affect anything though

I don't think so. Migrations are always sorted by date, and the ones from Breeze will just end up before all the user's migrations. If they would have been in the same directory, that's the order you can expect.

I quickly tested it in two apps with the following changes:

  private def migrated_migrations
    sorted_migrations.select &.new.migrated?
  end

  private def pending_migrations
    sorted_migrations.select &.new.pending?
  end

  private def sorted_migrations
    @@migrations.map { |m| {m, m.new.version} }
      .sort { |a, b| a[1] <=> b[1] }
      .map(&.[0])
  end

And it works fine. Not sure if this is the most elegant code, though. 😄

[jwoertink]

functional > elegant at this point 😂 If you would like to PR, that's cool or I can give that a shot later.

[wout]

This is probably better:

  private def sorted_migrations
    @@migrations.sort { |a, b| a.new.version <=> b.new.version }
  end

Yeah, sure, I'll create a PR for this. 🙂