[wp-trac] [WordPress Trac] #20875: Introduce wp_cache_get_multi()
WordPress Trac
noreply at wordpress.org
Thu Jun 2 14:57:46 UTC 2016
#20875: Introduce wp_cache_get_multi()
--------------------------------------------------+-----------------------
Reporter: nacin | Owner:
Type: enhancement | Status: reopened
Priority: normal | Milestone: 4.6
Component: Cache API | Version:
Severity: normal | Resolution:
Keywords: has-patch has-unit-tests 2nd-opinion | Focuses:
--------------------------------------------------+-----------------------
Comment (by boonebgorges):
Thanks, @dd32. There is lots of useful discussion in #31245, but that
ticket is covering two separate issues: (a) the implementation of
`get_multi()`, and (b) whether and how `get_multi()` can help to solve the
`alloptions` problem. Because we're developing good use cases for
`get_multi()` outside of `alloptions`, I would hate to see the Cache API
improvement held up because we can't come to a consensus about
`alloptions`.
I agree that going with a different function name probably makes sense,
given the compatibility concerns. `wp_cache_get_multiple()` seems best to
me.
In https://core.trac.wordpress.org/ticket/31245#comment:3, @rmccue asks:
> I'm not entirely sure on the _wp_cache_compat_get_multi naming/usage
pattern here, but doing it in a compatibility file requires us to either
define the function inside wp_start_object_cache or in a new file after
wp_start_object_cache but before default-filters.php is loaded. Thoughts?
This compatibility pattern seems bad to me because it means that we need
to a `function_exists()` check every time we want to use the new function.
I suggest loading a compatibility file *inside of*
`wp_start_object_cache()`. We do this already, when object-cache.php is
not found. [attachment:20875.4.diff] does this; it also switches to
`wp_cache_get_multiple()`, uses @rmccue's variable names instead of my
confusing ones, and simplifies by setting values not found in the cache to
be set to `false` (rather than leaving them out of the array altogether),
which makes the code simpler and is also closer to expected behavior, IMO.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/20875#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list