[wp-trac] [WordPress Trac] #20875: Introduce wp_cache_get_multi()

[WordPress Trac]

#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