[wp-trac] [WordPress Trac] #31245: Replace alloptions with a key cache

WordPress Trac noreply at wordpress.org
Tue May 9 06:13:18 UTC 2017


#31245: Replace alloptions with a key cache
-------------------------------------+-----------------------------
 Reporter:  rmccue                   |       Owner:  rmccue
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  Future Release
Component:  Options, Meta APIs       |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  performance
-------------------------------------+-----------------------------

Comment (by rmccue):

 I am personally strongly -1 on introducing `WP_Option`. Options are
 properties of sites, not fully-fledged objects. I am likewise strongly -1
 on introducing `wp_optionmeta` - to me, it'd be similar to introducing a
 `wp_postmetameta`.

 I'm ambivalent towards introducing a `WP_Option_Query`; I'm not sure
 options really need the full complexity that comes with a query class.
 That said, I think there is some utility in it, so I'm not against it.

 I am '''very strongly against treating options as objects''' however.
 Similar to how the meta tables are key-value stores for their parent
 objects (i.e. postmeta is a key-value store for the parent post), options
 are a key-value store for the parent site. The only real additional
 property that options have in the database (autoload) is a concession for
 performance, not a real additional properties. (The ID property has been
 functionally useless since 1.5, and apart from upgrade routines for v1.5
 and v2.9, is never used.)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31245#comment:51>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list