[wp-trac] [WordPress Trac] #20875: Introduce wp_cache_get_multi()
WordPress Trac
noreply at wordpress.org
Mon Mar 13 04:00:32 UTC 2017
#20875: Introduce wp_cache_get_multi()
-------------------------------------------------+-------------------------
Reporter: nacin | Owner:
Type: enhancement | boonebgorges
Priority: normal | Status: assigned
Component: Cache API | Milestone: Future
Severity: normal | Release
Keywords: has-patch has-unit-tests 2nd- | Version:
opinion | Resolution:
| Focuses:
-------------------------------------------------+-------------------------
Comment (by dd32):
> To move this forward, someone needs to make the call about syntax and
function naming. Authors of existing drop-ins (excepting @johnjamesjacoby)
don't seem eager to wade into this discussion, so I think we need an
executive decision. I nominate dd32 to make that decision,
I think we just need to choose the most sane function signature/return
values and go with it - but with the caveat that we can't use an existing
name if a common dropin has a conflicting method signature.
[attachment:20875.4.diff] seems sane to me, to recap it:
* `wp_cache_get_multiple( $groups )` which doesn't exist in the wild that
I can see - it's within the `wp_cache_` namespace, so if something private
has used it, good luck to them.
* Signature of `$groups` as `array( group1 => [ key1, key2 ], group2 => [
key3 ] );` IMHO looks sane and balances the complexity of fetching from
multiple groups while at the same time catering to it.
* Return signature of `array( group1 => [ key1 => value1, key2 => value2
], group2 => [ key3 => value3 ] )` matches the input signature, which
makes usability far more consistent.
Looking at real world use-cases:
* `$posts = wp_cache_get_multiple( [ 'posts' => [ 1, 2, 3 ] ]
)['posts'];`
* `$cache_data = wp_cache_get_multiple( [ 'posts' => [ 1 ], 'postmeta' =>
[ 1 ] ); $post = $cache_data['posts'][1]; $post_meta =
$cache_data['postmeta'][1];`
* `$option_names = [ 'option_1', 'option_2' ]; $options =
wp_cache_get_multiple( [ 'options' => $option_names ] );`
Moving forward on this ticket:
* I'd like to see the authors of the various object caches to be
consulted, with [attachment:20875.4.diff] as the suggested core patch (I
don't see a compiled list of object caches and their authors here)
* A quick yay-nay from each and maybe examples of how the cache would
implement it, to ensure that there's no unexpected surprises for authors.
(Such as the APC one in [attachment:20875-implementation-apc.php]). This
could be done by others as patches or PRs to projects too (Best to ask no
cache to implement the signature until core has a commit though!)
* A few examples of cases in WordPress where it can be utilised
immediately (through the compat wrapper) which shows it's beneficial and
actually offers improvements when implemented. (Such as done in
[attachment:20875-example-usage.diff]
From there, I think we're surprisingly in a good position to move forward
here.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/20875#comment:33>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list