Skip to content

[12.x] Handle Enum::cases() for enum column type #56565

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 3 commits into from
Aug 6, 2025
Merged

[12.x] Handle Enum::cases() for enum column type #56565

merged 3 commits into from
Aug 6, 2025

Conversation

iamgergo
Copy link
Contributor

@iamgergo iamgergo commented Aug 6, 2025

This PR adds a small modification due to the enum method in migrations, to make the development a bit more streamlined.

enum Role: string
{
    case ADMIN = 'admin';
    case MEMBER = 'member';
}
// Before
Schema::create('users', static function (Blueprint $table): void {
    $table->enum('role', ['admin', 'member']);
});

// After
Schema::create('users', static function (Blueprint $table): void {
    $table->enum('role', Role::cases());
});

Normally this PR has no breaking change, since the enum_value works with non-enums as well, returning the original value.

shaedrich
shaedrich reviewed Aug 6, 2025
View reviewed changes
Copy link
Contributor

@shaedrich shaedrich left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Migrations are intended to be non-dependent on other application code that is prone to change as this may break the migration at a later date. So, this is probably not what most devs want. What would work better, though, would be kind of a stub that would prefill the migration with the hard-coded enum values from that point.

@iamgergo
Copy link
Contributor Author

iamgergo commented Aug 6, 2025 •
edited
Loading

Migrations are intended to be non-dependent on other application code that is prone to change as this may break the migration at a later date. So, this is probably not what most devs want. What would work better, though, would be kind of a stub that would prefill the migration with the hard-coded enum values from that point.

I see this differently. There are already some methods  – like foreignIdFor(Model::class) – that depend on other part of the application. Also, at the end of the day the original way is still can be used if someone is afraid of breaking the code.

For me, the migrations are part of the same application as the enums or the models.

@taylorotwell taylorotwell merged commit b11b3c7 into laravel:12.x Aug 6, 2025
60 checks passed
@iamgergo iamgergo mentioned this pull request Aug 6, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@shaedrich shaedrich shaedrich left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@iamgergo @shaedrich @taylorotwell