Field column size improvements

[brandonkelly]

Description

Makes the following improvements for custom field content table columns:

• When adding or renaming a column, if a column with the same name already exists, a new table will be created (content_<columnName>_bak_<timestamp> to store the existing column’s non-null values, along with the rows’ id, elementId, and siteId values, and then the original column will be deleted from the content table. (Previously, the column was just renamed to <columnName>_old, adding to the table’s row size.)
• When changing a custom field’s column type, if a SQL error occurs due to the existing data being too long, the existing column data will be backed up in a new table, and then any existing values that would overflow the new column size will be set to null, then the alter table command will be attempted once again. (Previously, the column was just renamed to <columnName>_old and a new column was created, effectively wiping out the field’s existing values until manually reconstructed.)
• Dropdown and Radio Buttons fields now use smart column lengths, based on their longest option value’s length. (Note this doesn’t come into effect until the fields are re-saved.)

Example

If you have a Dropdown field with yes, no, and maybe options, its column type will be varchar(5) (instead of varchar(255) as before).

If its maybe option is removed later on, its column type will be changed to varchar(3). If any entries exist that had maybe selected, a new content_<columnName>_bak_<timestamp> table will be created, which will contain all of the non-null Dropdown field values, and then all maybe options will be set to null in the content table.

Related issues

• Matrix field hits the table row size limit. #2009
• table hits row size limit #4308
• Can no longer create new fields. Maximum table row size reached error warning.  #7221
• Database error - content table maximum rows exceeded #7750
• [4.4.5]: Using "Field Limit" after creating new "Plain Text Field" -> Database Exception #12954

[linear]

DEV-1103 Smart Dropdown/Radio Button column lengths

[Mosnar]

@brandonkelly Is there any risk of the automatic column resizing on option fields causing problems for people using the DefineInputOptionsEvent event? I'm not using it myself anywhere, but I've been keeping it in my pocket since it seems like it'd be really useful.

To be more specific, my thought is that since the resizing occurs when the field is saved, additional options defined via that event might be longer than what's supported by the column size.

[brandonkelly]

@Mosnar Good point! Yes, that could be an issue. And I don’t think we can safely call the event when determining the column length, because event handlers could return different options depending on the current entry, etc.

I’ve just added a new “Column Type” setting for Dropdown and Radio Buttons fields, which has two options – “Automatic” and “varchar”. The setting will be set to “varchar” for existing fields, and “Automatic” for new fields. So you will need to opt into the smart column sizing for existing fields (if you know it’s safe to do so), and you can opt out of it for new ones.

[lineke]

@brandonkelly Any chance this could be ported to Craft CMS 3?

[brandonkelly]

@lineke Craft 3 is now feature-locked. Bug/security fixes only now.

[lineke]

@brandonkelly We are now upgrading to craft 4 in order to solve the issue. Any idea when 4.5 will be released?

[brandonkelly]

@lineke Probably not for another month or so. You can start using it while it’s still in development by changing your craftcms/cms constraint in composer.json to 4.5.x-dev as 4.5.0 and running composer update.