Migration dependency ignored across databases

[jnigro]

Bug Description

According to the documentation, migration dependencies are declared by simply adding them in the proper order. However, these dependencies are inconsistently ignored if migrations are from different databases.

To Reproduce

To reproduce this, create two databases: Database A and Database B. Create one migration for each:

• Database A Migration: creates a table myTable
• Database B Migration: creates a view that selects the contents of the table in database A:

CREATE VIEW databaseB.myView AS SELECT * FROM databaseA.myTable;

Running these migrations may or may not work, depending on the order in which these migrations occur. This is not consistent, as the code in Migration.swift, maps a dictionary of the databases:

fluent-kit/Sources/FluentKit/Migration/Migrations.swift

Lines 1 to 2 in 7d9982a

	public final class Migrations {
	var storage: [DatabaseID?: [Migration]]

fluent-kit/Sources/FluentKit/Migration/Migrator.swift

Lines 108 to 113 in 7d9982a

	private func migrators<Result>(
	_ handler: (DatabaseMigrator) -> EventLoopFuture<Result>
	) -> EventLoopFuture<[Result]> {
	return self.migrations.storage.map { handler(.init(id: $0, database: self.databaseFactory($0), migrations: $1)) }
	.flatten(on: self.eventLoop)
	}

Since swift does not guarantee the order of a dictionary, you never know which database migrations will run first. This is a problem when a migration from one database has a dependency on an element from another database.

Expected behavior

I would expect migrations to be executed in the exact order as they are added, without grouping them by database.

Environment

• Vapor Framework version: 4.52.1
• Vapor Toolbox version: 18.3.3
• OS version: macOS 12.0.1

[mkll]

I would like to share an observation that even dependent migrations in the same database can fail, due to the fact that control is returned to the fluent-kit by database engine before the changes have actually been made to the database.

This is a slightly different problem than the one discussed, but the result is about the same. I ended up creating duplicate PostgreSQL configurations with a 1-connection limit, and that alone helped serialize the migrations in a strict sequence without overlapping. As far as I understand, this problem cannot be solved at the Swift level at all.