Skip to content

Kindly consider restoring enum support #907

@janwittkamp

Description

@janwittkamp

While upgrading to the latest minor release, our test suite started failing because several of our migrations define ENUM columns. We traced this to commit b068c3301472, which removed support for the enum column type (workaround in #895 not feasible).

We’ve read issue #895 and tried the suggested workaround, but in our codebase it either doesn’t work reliably or would require a non-trivial amount of changes to existing migrations—which feels like a lot for a minor upgrade. As a result, we’re temporarily pinning to 4.6.6.

A public GitHub search already shows hundreds of files using ->addColumn('…', 'enum', …).
Search query:

/->\s*addColumn\(\s*['"][^'"]+['"]\s*,\s*['"]enum['"]\s*,\s*(?:\[|array\()\s*/ lang:PHP

Many of these are in the Phinx ecosystem (which Migrations is built on).

Expectations around compatibility. Since Migrations sits on top of Phinx, many of us assumed enum would continue to behave as before. Seeing it disappear was a bit surprising during a minor upgrade.

Modeling existing schemas. MySQL/MariaDB (and PostgreSQL via CREATE TYPE … AS ENUM) support enums natively. Some teams—including us—use them intentionally to express constrained domains. Losing the type means larger refactors or workarounds for existing databases.

Is there a planned workaround or recommended path for projects currently relying on enum (e.g., a configuration toggle, adapter setting, or documented interim approach)?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions