[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