Migrations: semantic versioning or dependencies? Odd behavior

I’ve been experimenting with Migrations and data models as we work through functionality for our UF site. I’ve been using semantic versioning almost exclusively to ensure the proper sequencing of migration code runs as we iterate. Recently, though, as we lock down the MVP for our project, I thought it best to code in the dependencies for each Migration as we run them against our candidate for production release and prepare to enter alpha testing.

In doing that, I’ve encountered a behavior from Bakery Migrate that appears to me to be inconsistent with my understanding of Bakery’s capacity to sequence Migrations to meet dependencies among pending migrations in the same batch. I’m basing this on the following sentences from the Migrations docs in learning:

" If those migrations are not yet executed and are pending execution, the migrate command will take care of the order automatically. If a migration’s dependencies cannot be met, the migrate command will abort."

That being said, I tried to run several table migrations using both semantic versioning and dependency declaration attributes. And after several attempts with results that are similar to that below, I ran a single migration on which several others are dependent, ensured that it was recorded in the migrations table, ensured that its versioning is correct in dependency attributes and namespace, and Bakery Migrate STILL came back with dependency errors suggesting that several migrations could not be fulfilled due to a failure in dependency checks - even when the required dependency was both present in the semantic version directory AND recorded in the migrations table. Here’s the output from Bakery Migrate:

$ php bakery migrate --pretend -vvv

UserFrosting’s Migrator

Testing database connexion
Ok

Installed migrations:
\UserFrosting\Sprinkle\Core\Database\Migrations\v400\SessionsTable
\UserFrosting\Sprinkle\Core\Database\Migrations\v400\ThrottlesTable
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\ActivitiesTable
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\UsersTable
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\RolesTable
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\RoleUsersTable
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\CreateAdminUser
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\GroupsTable
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\PasswordResetsTable
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\PermissionRolesTable
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\PermissionsTable
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\PersistencesTable
\UserFrosting\Sprinkle\Account\Database\Migrations\v400\VerificationsTable
\UserFrosting\Sprinkle\SiteAccount\Database\Migrations\v100\GroupBrandsTable

Fetching available migrations

Fetching from core
Fetching from site-core
Fetching from account
Fetching from site-account
Fetching from admin
Fetching from site-admin
Fetching from site

Pending migrations:
\UserFrosting\Sprinkle\SiteAccount\Database\Migrations\v100\SKUsTable

Resolving migrations dependencies…

Checking dependencies for \UserFrosting\Sprinkle\SiteAccount\Database\Migrations\v100\SKUsTable

Fulfillable migrations:

Unfulfillable migrations:
\UserFrosting\Sprinkle\SiteAccount\Database\Migrations\v100\SKUsTable

[ERROR]
Some migrations dependencies can’t be met. Check those migrations for
unmet dependencies and try again:
\UserFrosting\Sprinkle\SiteAccount\Database\Migrations\v100\SKUsTable
depends on
-
UserFrosting\Sprinkle\SiteAccount\Database\Migrations\v100\GroupBrandsT
able

What am I overlooking?

Assuming the pasted text is correct, it might be as simple as a missing / in your dependent migration name:

depends on

UserFrosting\Sprinkle\SiteAccount\Database\Migrations\v100\GroupBrandsT
able

Should be \UserFrosting\Sprinkle\SiteAccount\Database\Migrations\v100\GroupBrandsTable, with the \ at the beginning, like it’s listed in the Installed migrations list.

That said, the doc might not be 100% about this, but the foolproof way to make sure migration are run in order is to use dependencies. Semantic version is more of a way to keep organized (all v3 migration together, etc.).

I branched out what appeared to be anomaly after posting this report, then forced the existing migrations to run by commenting out the dependency attributes and forcing semantic versioning in sequential directories. At the end of the day, I’ll checkout the branch with the offending dependency attributes and add the leading \ to check your hypothesis. I expect that it’s right.

That was, indeed, the issue. Thanks for the sharp eye.