phinx: BC break mitigation strategy

https://github.com/cakephp/phinx/pull/1899 Since Phinx 0.13, foreign key columns have to be specified with "signed" => false

Also refs https://github.com/cakephp/migrations/issues/599

That causes now BC breaks in all kind of applications due to plugins not containing this

PDOException: SQLSTATE[HY000]: General error: 1005 Can’t create table release_local.state_machine_item_states (errno: 150 “Foreign key constraint is incorrectly formed”) in /shared/httpd/release/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:192

due to https://github.com/spryker/cakephp-statemachine/blob/81b6ca3c9fddf5dbacc8d863f4096f77a9d6c4c5/config/Migrations/20161029230233_StateMachineInit.php

Why was this a requirement again? Why couldnt we continue to treat also unsigned ones as valid foreign key columns and just use signed on by default then? I would only expect the generation of new migration files to be “more specific”, while keeping support for every file so far.

https://github.com/spryker/cakephp-statemachine/commit/953489cd55fec731dcccda59567ecfcd1fc2f16b seems to be needed, instead, maybe we could offer some migration to provide this where needed instead of just failing hard? Not sure what could be done here.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 20 (20 by maintainers)

Most upvoted comments

Couldn’t this be worked around by reintroducing the previous default in \Migrations\Table::create()?

That said: You could also do the other way around: Revert both and add feature flags to restore the current master behavior for both topics. Then only 0.14 could maybe switch feature flag behavior and we have more time to figure things out. Consumers can read in release notes on how to enable better defaults by enabling the feature flags on their own if e.g. new project or safe to do so.

https://old.reddit.com/r/shittychangelog/comments/zl5gaz/here_at_reddit_we_believe_everything_is_better_in

If even reddit overflowed 32bit signed int only now I am not sure the grief this change caused was worth it.

I also ran into my migrations being ‘broken’ by this change. Tracking down where each foreign key was added to the schema and updating those migrations was pretty tedious.