Opened 8 years ago
Closed 6 years ago
#7435 closed enhancement (fixed)
XProfile caching: The Next Generation
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.0.0 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Extended Profile | Keywords: | has-unit-tests has-patch |
Cc: | dcavins |
Description
I'm currently building a member directory that uses a tabular format, populated by xprofile data. Pulling up this data is painful, for a couple of reasons:
BP_XProfile_Field::get_id_from_name()
is uncached, which means that I have to build my own name/id map to avoid all the extra lookups. This makes it unfeasible to usexprofile_get_field_data()
BP_XProfile_Group::get()
has a few uncached queries, which makes building the map fairly expensive- My alternative strategy of calling
BP_XProfile_ProfileData::get_all_for_user()
in the loop ran into some of the same problems
Let's think about ways to unify the caching strategy (or lack thereof) in these areas with what's happening through the rest of XProfile.
Attachments (1)
Change History (14)
#4
@
6 years ago
- Milestone changed from Awaiting Contributions to 4.0
I've started work on this and would like to squeeze at least part of it into 4.0, if possible.
7435.diff breaks up BP_XProfile_Group::get()
somewhat, so that the group ID query and the field ID queries take place in different methods: get_group_ids()
and get_group_field_ids()
. They're meant for internal use, and are public only so that it's easier to test them. Each of them has its own caching layer, both of which are tied to the bp_xprofile_groups
incrementor. I'm using the same incrementor for each, because any changes to *either* groups or fields can result in the queries being thrown off (because of hide_empty_groups
etc). I'm then using the SQL statement to generate a cache key.
I've made an attempt to cover the invalidation cases. I've erred on the side of too-much-invalidation: we bust the incrementor anytime a group or a field is saved or deleted. Updating field/group order also needs its own invalidation, because it doesn't run through save()
.
This thought process - especially invalidation - could use another set of eyes. Maybe @dcavins ? I can work on more caching, but what's suggested here would be a good start.
#5
@
6 years ago
I'm happy to help, Boone. I will test your patch next week for starters, then we can go from there. Thanks for improving the caching in BP everywhere.
This ticket was mentioned in Slack in #buddypress by boone. View the logs.
6 years ago
This ticket was mentioned in Slack in #buddypress by dcavins. View the logs.
6 years ago
#10
@
6 years ago
I've reviewed the patch and I think it's ready to go. I'd like to get it in so that we can work on some additional improvements in this area.
Moving to 3.0, but bump to FR if needed.