[wp-trac] [WordPress Trac] #34047: Split up `wp_lazyload_term_meta()`; check `$check` before lazyloading

[WordPress Trac]

#34047: Split up `wp_lazyload_term_meta()`; check `$check` before lazyloading
-------------------------+--------------------
 Reporter:  dlh          |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  4.4
Component:  Taxonomy     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+--------------------

Comment (by boonebgorges):

 Thanks, dlh! This discussion is helping me to clarify what I think is the
 best way forward.

 > The only other situation I had in mind is where I knew I didn't need the
 meta at all for my particular query -- rare as that might be, true enough.

 The "lazy" part of the lazyload means that nothing is queried until it's
 first used. That is: if you never call `get_term_meta()` within the loop,
 then no queries against `wp_termmeta` will ever take place. So no overhead
 is added at all.

 > In 34047.2, it still happens that one get_term_meta() call is enough to
 fire get_term_metadata and prime every existing query's cache that needs
 it.

 Yeah, I see what you mean. Say you have code like the following:

 {{{
 wp_set_object_terms( 1, 'Foo', 'post_tag' );
 wp_set_object_terms( 2, 'Bar', 'post_tag' );
 wp_set_object_terms( 3, 'Baz', 'post_tag' );
 wp_set_object_terms( 4, 'Quz', 'post_tag' );
 $q1 = new WP_Query( array( 'include' => array( 1, 2 ) ) );
 $q2 = new WP_Query( array( 'include' => array( 3, 4 ) ) );
 }}}

 At this point, the first time you call `get_term_meta()`, termmeta for
 both `$q1` and `$q2` is going to be loaded - that is, all the metadata
 belonging to 'Foo', 'Bar', 'Baz', and 'Quz'.

 I suppose one way to do somewhat more targeted lazyloading is to bail if
 the `$term_id` passed to `get_term_meta()` doesn't belong to any of the
 posts in the loop. This is not foolproof: if Quz belongs to post 1 as well
 as post 3, then `get_term_meta( $quz_id, 'foo' )` would prime the caches
 for *both* loops. But maybe it's better than nothing.

 > Add update_term_meta_cache to the $args array in
 WP_Query::parse_query(). If true, does the same priming as the other
 patches here.

 I'm leaning against doing this. 'update_post_term_cache' means: after
 querying posts, prime the term cache for each post immediately. That
 action invokes a not-insignificant amount of overhead. What we're talking
 about here is more subtle: after querying posts, we do *not* prime
 termmeta cache; we set up lazyloading, so that the data is loaded only
 when we need it. This introduces basically zero overhead, and I'm not sure
 it's something that you need to be able to turn off (and, as noted, you
 can do it if you really need to).

 As a side note, I think that the lazyloading technique we're talking about
 here is, in most ways, preferable to the 'update_post_meta_cache' and
 'update_post_term_cache' techniques that `WP_Query` currently uses. If it
 works out well for termmeta and commentmeta, we should consider migrating
 other cache priming to the lazyload model in the future.

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