[buddypress-trac] [BuddyPress Trac] #6242: Possible conflict with BuddyPress member type user cache and the WordPress term cache

[buddypress-trac]

#6242: Possible conflict with BuddyPress member type user cache and the WordPress
term cache
--------------------------+--------------------
 Reporter:  imath         |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  2.2.2
Component:  API - Cache   |     Version:  2.2
 Severity:  normal        |  Resolution:
 Keywords:  2nd-opinion   |
--------------------------+--------------------

Comment (by johnjamesjacoby):

 Replying to [comment:4 boonebgorges]:
 > But BP is *not* caching a list of term objects. We're caching an array
 of term `name`s.

 OIC.

 > It's also not quite true that we only use the cache when looking at
 single members. Member type data is prefetched in member loops (see
 `bp_members_prefetch_member_type()`.
 Yes, but the individual caches are still for each single member, retrieved
 via `bp_get_non_cached_ids()`.

 > I'm going to go with `_value`, because it's a bit clearer that what's
 being cached is the value for a given member (strictly speaking, a
 term_relationship), not the type itself (which is a term).
 Since the collision (and confusion) is between: values for the member-type
 itself, and values for the member, -- can we aim for something that
 addresses that ambiguity? `bp_member_member_type` even?

 -----

 Worth noting this is only an issue on single-site installations, because
 `bp_member_type` is a global cache group and gets prefixed differently as
 a result in multisite. Yes, we absolutely want to avoid cache pollution,
 but we could also do that with a namespace for all of our cache groups,
 like `bp_cache_` or something?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6242#comment:5>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac