mirror of
https://github.com/koel/koel.git
synced 2026-04-25 16:56:02 +03:00
[GH-ISSUE #1975] [Bug]: Database migration issue with 7.6.3 #1050
Labels
No labels
Authentication
Dependencies
Documentation
Feature Request
Flac
Help Wanted
Installation/Setup
Integration
Mobile
PR Welcome
Pending Release
Performance
Playlist
S3
Search
Sync
[Pri] Low
[Pri] Normal
[Status] Keep Open
[Status] Needs Author Reply
[Status] Needs Review
[Status] Stale
[Status] Will Implement
[Type] Blessed
[Type] Bug
[Type] Duplicate
[Type] Enhancement
[Type] Help Request
[Type] Question
[Type] Task
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/koel-koel#1050
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nebulade on GitHub (Jun 28, 2025).
Original GitHub issue: https://github.com/koel/koel/issues/1975
Originally assigned to: @phanan on GitHub.
Read the Troubleshooting guide.
Reproduction steps
Expected behavior
Initial db migration/setup works
Actual behavior
Setup fails with:
Logs
Koel version
7.6.3
How did you install Koel?
Compiled from source
Additional information
@phanan commented on GitHub (Jun 28, 2025):
What’s the db version?
On Sat, Jun 28, 2025 at 14:28 Johannes Zellner @.***>
wrote:
@nebulade commented on GitHub (Jun 28, 2025):
Sorry for late answer, will debug later today a bit, just wanted it to be logged here already.
The MySql version is
Ver 8.0.41-0ubuntu0.24.04.1 for Linux on x86_64 ((Ubuntu))Otherwise this is from an empty database, in case you asked for the migration step at which the script starts with.
@phanan commented on GitHub (Jun 28, 2025):
This is curious then 🤔 . The CI uses MariaDB (should be compatible with MySQL, at least for these stuff) on a blank state of course, and it didn't report this error.
@nebulade commented on GitHub (Jun 28, 2025):
I managed to look into this a bit, although I am not a laravel expert. So commenting out the failing line at
github.com/koel/koel@befb8a33ed/database/migrations/2025_06_16_141017_create_organizations_table.php (L36)obviously makes it work. Now if I interpret that migration script correctly, it first creates the column with allowing null values, then creates the foreign key and then tries to adjust the column to not allow null values (which is failing).Presumably
DB::table('users')->update(['organization_id' => Organization::default()->id]);in-between will somehow set the column for existing rows (where null) to some default value, which then allows for it to be non-null from here on. Apparently mysql then unlike mariadb does not allow column schema changes after used in foreign keys this way. Is there a way in laravel to reorder this and only setup the foreign key after setting initial values? Question might sound stupid, but I am not quite sure what that line above does.@phanan commented on GitHub (Jun 28, 2025):
Thanks for the details. I think instead of adding the foreign key/index, setting the value, and then trying to modify it, we can just move the foreign key/index creation to after setting the value. This way, forcing
users.organization_idto NOT NULL shouldn't clash with any index. WDYT?@phanan commented on GitHub (Jun 28, 2025):
Something like this:
Do you think you can try this out and let me know if it works?
@nebulade commented on GitHub (Jun 28, 2025):
ah same idea/solution then (see PR). Yes that worked fine for me
@phanan commented on GitHub (Jun 28, 2025):
That's super fast! Thank you. Let's wait for the CI and I'll merge it.
@phanan commented on GitHub (Jun 28, 2025):
ICYMI, I've tagged a new version that includes this fix. Thanks again for the great help!
P.S. Cloudron looks super dope!