Add support for Partitions to plans

[jamisonbryant]

Summary

Plans silently drop Partition-related actions because they don't match any of the action type checks in any of the gather*() methods: gatherUpdates(), gatherTableMoves(), gatherIndexes(), or gatherConstraints(). The actions exist but are never added to any of the execution sequences, so executeActions() is never called with them.

Refs #986

Changes Made

Added a gatherPartitions() method to Plan.php that handles AddPartition/DropPartition

[jamisonbryant]

Before fix:

❯ bin/cake migrations migrate -x -c test_partitions -s Partitions
DRY-RUN mode enabled

 == 20260105211436 PartitionFoosTable: migrating
INSERT INTO phinxlog (version, migration_name, start_time, end_time, breakpoint) VALUES (:c0, :c1, :c2, :c3, :c4)
 == 20260105211436 PartitionFoosTable: migrated 0.0907s
All Done. Took 0.5902s

After fix:

❯ bin/cake migrations migrate -x -c test_partitions -s Partitions
DRY-RUN mode enabled

 == 20260105211436 PartitionFoosTable: migrating 
ALTER TABLE `foo_partitioned` ADD PARTITION (PARTITION `p2023` VALUES LESS THAN ('2024-01-01')), ADD PARTITION (PARTITION `p2024` VALUES LESS THAN ('2025-01-01')), ADD PARTITION (PARTITION `p2025_01` VALUES ... ADD PARTITION (PARTITION `pmax` VALUES LESS THAN MAXVALUE);
INSERT INTO phinxlog (version, migration_name, start_time, end_time, breakpoint) VALUES (:c0, :c1, :c2, :c3, :c4)
 == 20260105211436 PartitionFoosTable: migrated 0.1093s
All Done. Took 0.6625s

[jamisonbryant]

I am not 100% sure this is generating valid SQL just yet, please hold.

[dereuromark]

The fix is correct and complete. The same bug pattern could theoretically affect any new action type added in the future - Plan.php must always be updated when new action classes are introduced.
Good catch there.

I added some postgres tests.

[jamisonbryant]

Thanks for adding the Postgres tests. There's a problem still, though.

ALTER TABLE foo_partitioned ADD PARTITION (PARTITION p2023 VALUES LESS THAN ('2024-01-01')), ADD PARTITION ...

everything from the 2nd 'ADD PARTITION' onward is invalid, at least in MySQL (I don't have a Postgres test bench atm). This is what MySQL wants instead:

ALTER TABLE foo_partitioned ADD PARTITION (PARTITION p2023 VALUES LESS THAN ('2024-01-01'), PARTITION p2022 VALUES LESS THAN (...));

Me and Claude are working on it, just wanted to raise the flag that I'm not 100% on this yet.

[dereuromark]

Cool OK
It probably tells you sth similar:

Options to fix this:

1. Batch in gatherPartitions() - Combine multiple AddPartition actions for the same table into a single execution that generates one ADD PARTITION (...) with comma-separated partition definitions
2. Fix in the SQL generator - Modify how AlterTable generates SQL for partition actions to batch them automatically
3. Different action class - Use a single AddPartitions (plural) action that holds multiple partition definitions instead of multiple AddPartition actions

Option 1 is likely the cleanest since Plan.php already groups actions by table - it just needs to ensure partition actions are combined into a single ALTER statement rather than being executed as separate ADD PARTITION clauses joined by commas.

[dereuromark]

#988 might fix it all

[dereuromark]

Sry, pushed that one to the wrong branch.

[jamisonbryant]

Closing in favor of #988