Opened 3 years ago
Last modified 7 months ago
#13310 new enhancement
Extend option_name to varchar(255)
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | Database | Version: | 3.4.2 |
| Severity: | normal | Keywords: | has-patch 2nd-opinion |
| Cc: | fabio84 |
Description
option_name is currently set to varchar(64). This raises problems when one tries to use transients with slightly longer names and a timeout:
_transient_timeout_feed_mod_23a137101df6920fbf6047... has 60 chars already.
Attachments (1)
Change History (7)
- Keywords 2nd-opinion added
Yeah, no way we're rushing in a schema change. I'm not sure it's necessary, frankly.
Going to leave the unassigned milestone and tag for 2nd-opinion, but expecting wontfix.
comment:4
chrisbliss18 — 3 years ago
This isn't a bad idea. Especially the specific length.
The get_site_option function uses the options table when the site isn't multisite and uses the sitemeta table when it is multisite. This translates into a maximum name size of 64 characters (length of option_name) for site option storage for non-multisite and 255 characters (length of meta_key) for multisite.
- Cc fabio84 added
- Version set to 3.4.2
Wow, in 2 years you were not able to make option_name a varchar(255)... I tried to use get_transient and set_transient, but I got stuck by this "feature".
As reported also in #15058 with transient values the limit is 45 characters, and if you use hashes and long identifiers to avoid collisions it's quite easy to reach the limit.
Please excuse me for this rant, but developing WordPress plugins using its APIs sometimes is frustrating.

This schema change would have a significant impact on large WP networks.
IMO, it should be punted to 3.1 to give admins of large installs an opportunity to implement the schema change prior to running the upgrade.