"Data too long for column 'code' at row 1" #929
Comments
|
Also running into this issue. Can't load any projects (getting a 404) and have |
|
After comparing my current install's schema versus a fresh install, I had the run the following MySQL commands to fix my install. Was there missing migrations? |
|
Not sure yet but this may be the culprit: https://docs.djangoproject.com/en/5.0/releases/5.0/#migrating-uuidfield |
|
The Up until Django 4.2.8, UUID fields were stored in varchar(32) columns. MariaDB 10.7 introduced a native UUID data type, and Django 5.0 switched to using that. The problem is that existing databases still have varchar(32) columns. The Django documentation proposes a migration path: create a subclass of UUIDField class backed by char(32). I think this would be problematic in Healthchecks case:
Here's the Django ticket where the varchar(32) -> UUID change was proposed and discussed: https://code.djangoproject.com/ticket/33507 The developers do discuss an alternative migration path: "alter table ... modify column ... uuid". They conclude this approach would be tricky when UUIDs are used as foreign keys. Constraints would need to be dropped, then recreated after migration – ugh! But luckily in Healthchecks case, we do not use UUIDs as foreign keys anywhere, so perhaps this could still work for us? I reproduced the
I then dropped into the database shell, and ran the following commands to convert varchar(32) columns to UUID: ALTER TABLE accounts_credential MODIFY COLUMN code UUID NOT NULL;
ALTER TABLE accounts_project MODIFY COLUMN code UUID NOT NULL;
ALTER TABLE api_channel MODIFY COLUMN code UUID NOT NULL;
ALTER TABLE api_check MODIFY COLUMN code UUID NOT NULL;
ALTER TABLE api_check MODIFY COLUMN last_start_rid UUID;
ALTER TABLE api_notification MODIFY COLUMN code UUID NOT NULL;
ALTER TABLE api_ping MODIFY COLUMN rid UUID;After this, the Healthchecks instance appears to be nominally working, that is, I don't see any obvious issues yet. So I'm thinking about the following path forward:
PS. Why not run the "alter table" commands automatically in a migration? Because they should only be run on MariaDB databases 10.7+. Suppose you are currently using MariaDB 10.6 (this is what ships with Ubuntu 22.04 for example). A migration that converts varchar(32) to UUID would fail, because MariaDB 10.6 does not have UUID datatypes yet. So you would be stuck unable to complete migrations. |
|
No feedback and no other problem reports, so I will leave this as-is for now. |
|
I have tested the database changes now about 4 weeks with 3 instances of heathchecks. What do you mean? |
|
I think this cannot be a migration–
This could be be packaged into a management command that the site operator runs manually when/if needed though. |
|
I think it should be possible to check the mariadb version with a "SELECT VERSION()" statemant after the connection to the db is initialized. If the result under version 10.7.x we can do a automated migration. Otherwise we should note this behavior in the docs or set a recommend version like 10.7.x |
Had the same problem. The SQL statements fixed that for me as well. Thank you! |
|
I added a system check which tests if we're running on MariaDB 10.7+ with varchar instead of uuid datatypes. If positive, it outputs: To anyone finding this comment by following the link in the error message, the recommended steps are:
ALTER TABLE accounts_credential MODIFY COLUMN code UUID NOT NULL;
ALTER TABLE accounts_project MODIFY COLUMN code UUID NOT NULL;
ALTER TABLE api_channel MODIFY COLUMN code UUID NOT NULL;
ALTER TABLE api_check MODIFY COLUMN code UUID NOT NULL;
ALTER TABLE api_check MODIFY COLUMN last_start_rid UUID;
ALTER TABLE api_notification MODIFY COLUMN code UUID NOT NULL;
ALTER TABLE api_ping MODIFY COLUMN rid UUID; |
Hello everyone,
unfortunately, Heathchecks no longer works in conjunction with a MariaDB. The problem occurred after the update to version 3.1. MariaDB version 10.8.8 is used. In my understanding the string is too long for the column? But my knowledge from coding is very limited.
docker-compose.yml
Logs:
The text was updated successfully, but these errors were encountered: