[wp-trac] [WordPress Trac] #37198: Use `WP_Term_Query` for `wp_get_object_terms()`

[WordPress Trac]

#37198: Use `WP_Term_Query` for `wp_get_object_terms()`
-------------------------+---------------------------
 Reporter:  flixos90     |       Owner:  boonebgorges
     Type:  enhancement  |      Status:  assigned
 Priority:  normal       |   Milestone:  4.7
Component:  Taxonomy     |     Version:  4.6
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+---------------------------
Changes (by boonebgorges):

 * keywords:  has-patch 2nd-opinion => has-patch
 * owner:   => boonebgorges
 * status:  new => assigned


Comment:

 > I think it's term_order, other than that it appears to be good solution.
 :)

 Whoops :)

 > That's interesting. I don't think it will be a problem since the caches
 shouldn't interfere with each other.

 Right. For posterity's sake, here's how it'll work in practice. Functions
 like `get_the_terms()`, which call `get_object_term_cache()`, do something
 like the following:

 {{{
 1. $terms = get_object_term_cache( $post_id, $taxonomy );
 2. if ( false === $terms ) {
 3.    $terms = wp_get_object_terms( $post_id, $taxonomy );
 4.    // then set the {$taxonomy}_relationships cache
 5. }
 }}}

 Under normal circumstances, one of the following conditions will hold:
 a. The relationship cache is full, and so is hit on line 1.
 b. The relationship cache is empty, but the cache related to the
 `wp_get_object_terms()` call is full, so that cached value is returned and
 used to populate the `{$taxonomy}_relationships` cache.
 c. The relationship cache is empty, as is the `wp_get_object_terms()`
 cache. The database is hit and the term query cache is populated. This is
 then used to populate the `{$taxonomy}_relationships` cache.

 > What we could theoretically do is actually make use of that cache in
 wp_get_object_terms()

 That's an interesting thought. Essentially, it'd save us a JOIN against
 `wp_term_relationships`. Let's explore the possibility in a separate
 ticket, with some benchmarks. (It'll take a bit of confusing code to make
 it work right, so it's not worth doing if it doesn't result in visible
 benefits.)

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