WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 5 months ago

#13310 new defect (bug)

Extend option_name to varchar(255)

Reported by: scribu Owned by: ryan
Milestone: Future Release Priority: normal
Severity: normal Version: 3.4.2
Component: Database Keywords: has-patch 2nd-opinion
Focuses: Cc:

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)

schema.diff (561 bytes) - added by scribu 4 years ago.

Download all attachments as: .zip

Change History (19)

scribu4 years ago

comment:1 wpmuguru4 years ago

  • Keywords commit removed
  • Milestone changed from 3.0 to Unassigned

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.

comment:2 nacin4 years ago

  • 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:3 scribu4 years ago

Related: #15058

comment:4 chrisbliss184 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.

comment:5 nacin3 years ago

  • Milestone changed from Awaiting Review to Future Release

comment:6 fabio8418 months ago

  • 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.

Last edited 18 months ago by SergeyBiryukov (previous) (diff)

comment:7 follow-up: tivnet11 months ago

  • Type changed from enhancement to defect (bug)

Still not fixed in 2013!
Version: WP 3.6-beta3-24265

Example of the error:

[22-May-2013 22:29:06 UTC] WordPress database error
Data too long for column 'option_name' at row 1 for query
INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`)
VALUES ('_transient_timeout_woocommerce-gateway-paypal-express/woocommerce-gateway-paypal-express.php_version_data'

@SergeyBiryukov - varchar(255) - is that really hard to make? While 3.6 is still in beta...

comment:8 tivnet11 months ago

  • Cc gregory@… added

comment:9 follow-up: markoheijnen11 months ago

I do agree that we should fix it but the error you have is also stupid from WooCommerce or the PayPal plugin.

comment:10 in reply to: ↑ 9 ; follow-up: tivnet11 months ago

Replying to markoheijnen:

I do agree that we should fix it but the error you have is also stupid from WooCommerce or the PayPal plugin.

Well, why this error is more stupid than that one from @Scribu, the original reporter? Anyway, I believe, there is no reason to keep varchar(64) these days, whether the transients are stupid or smart :-)

comment:11 in reply to: ↑ 7 ; follow-up: SergeyBiryukov11 months ago

Replying to tivnet:

@SergeyBiryukov - varchar(255) - is that really hard to make? While 3.6 is still in beta...

It's simple on single site installs, but can be an issue on large network installs, as noted in comment:1.

We're in late beta, when lots of things are being punted to a future release. Anything that requires a schema change should be brought up early in the cycle.

comment:12 in reply to: ↑ 10 markoheijnen11 months ago

Replying to tivnet:

Replying to markoheijnen:

I do agree that we should fix it but the error you have is also stupid from WooCommerce or the PayPal plugin.

Well, why this error is more stupid than that one from @Scribu, the original reporter? Anyway, I believe, there is no reason to keep varchar(64) these days, whether the transients are stupid or smart :-)

The name of the transient is way too long. It's includes the plugin location of the plugin with the name. So for a fast fix you should contact WooCommerce team and see what they can do.

comment:13 in reply to: ↑ 11 tivnet11 months ago

We're in late beta, when lots of things are being punted to a future release. Anything that requires a schema change should be brought up early in the cycle.

Well, I guess this is a dead horse then. 3 years ago was not early enough :-)

Started with that, but... it will probably take 5 years to Woo, if it takes 3 years to WP :-)

Thank you!

Last edited 8 months ago by nacin (previous) (diff)

comment:14 ocean908 months ago

#25035 was marked as a duplicate.

comment:15 betzster8 months ago

  • Cc j@… added

comment:16 sc0ttkclark5 months ago

  • Cc lol@… added

comment:17 tivnet5 months ago

Celebrating 4 years of this soon... MAZAL TOV! :-)))

comment:18 sc0ttkclark5 months ago

I'd really like to see this move forward, what's exactly the holdup? Is it the lack of use-cases for using longer option names? If that's the case, I'd think that most use-cases currently use bad hack arounds and just deal with it, and the lack of characters in option_name begets use-cases for longer character use.

Note: See TracTickets for help on using tickets.