Repository navigation
Group migration sets that share a migration history - #1116
Merged
Merged
Conversation
Migrator::runMany() decided whether to drop tables once per migration set. A migration history is keyed by connection and plugin only, never by source, so two sets differing only in their source write to one history while each of them sees just its own directory on disk. Every set therefore reported its siblings' applied migrations as missing, and the connection was wiped on every run even when the database was already up to date. Sets are now grouped by the history they share, and a logged migration found on disk in any set of the group no longer counts as missing. testRunManyMultipleSkip relied on that spurious drop to trigger its failure, so it now forgets an applied migration to give the second run a genuine reason to drop. It no longer has to be skipped when the unified table is in use.
markstory
reviewed
Sep 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1115.
Migrator::runMany()evaluatesshouldDropTables()once per migration set, but a migration history is keyed by connection and plugin only.ManagerFactory::createConfig()derives the log table fromUtil::tableName($plugin), and the unifiedcake_migrationstable filters on itsplugincolumn. The source folder never enters either.Two sets that differ only in
sourcetherefore share one history while each sees only its own directory on disk.Manager::printStatus()compares the whole log against one source's files and flags everything belonging to the sibling source as applied but missing.shouldDropTables()then returns true, and the connection is dropped and its history truncated on every run, even when the test database is current. Legacyphinxlogtables are affected in the same way.The fix groups sets by their shared history, using the connection and plugin, and collects the migration IDs present on disk across the group. A logged migration found in any source of the group no longer counts as missing. Sets with distinct histories retain their previous behavior.
The sibling migration IDs are passed as an optional third parameter to
shouldDropTables(). This keeps the data flow explicit, but changes the signature of a protected method. Existing subclasses that override the two-parameter method would need to accept the new optional parameter.testRunManyMultipleSkipwas passing because of the unwanted drop, so it now forgets one applied migration to give the second run a valid reason to drop. That also allows it to run against the unified table, so itsskipIfis gone.Both new tests fail on 5.x and pass with the fix in legacy and unified mode.