Skip to:
Content

BuddyPress.org

Opened 11 years ago

Closed 6 years ago

#4796 closed enhancement (maybelater)

Use taxonomies instead of/in addition to BP Xprofile tables

Reported by: boonebgorges's profile boonebgorges Owned by: boonebgorges's profile boonebgorges
Milestone: Priority: normal
Severity: normal Version:
Component: Extended Profile Keywords: trac-tidy-2018
Cc: vpundir@…, vivek@…, emzo, jonathan@…

Description

BP's xprofile tables store profile field data (and metadata about fields) in what are essentially key-value pairs. This works well when querying by user id, which is what generally happens on the user profile pages and elsewhere in BuddyPress. However, the unindexed value column means that it's basically impossible to do more complex queries - stuff like "how many users live in Wisconsin or New York, and also are less than 100 years old?". It's technically possible to make these kinds of things work - see http://wordpress.org/extend/plugins/bp-better-directories/ - but the JOINs required are very ugly and very unscalable.

Profile data is many-to-many in structure. And WordPress already has a system for many-to-many metadata: custom taxonomies. I'd like to propose that xprofile field data be stored in a taxonomy instead of a key-value table.

Benefits:

  • Exponentially faster complex queries
  • We can leverage the core taxonomy API, including caching
  • We can remove a bunch of stuff from BP

Concerns:

  • Backward compatibility with existing plugins/themes
  • Pain in the butt to port
  • Some field types do not lend themselves well to taxonomies. In particular, it would be odd to store <textarea> data (multi-line text box) in a taxonomy

I'd want for the xprofile component (at least the query class) to have pretty complete test coverage before attempting anything like this.

Obviously a long-term project and perhaps a pipe dream, but IMO it's one of the most promising areas in BP for getting rid of a custom table or two, while also giving us a ton of cool new features.

Change History (16)

#1 @johnjamesjacoby
11 years ago

Conceptually, it's definitely an improved data schema. Like we've talked about in the past, this goes into the 'picking a data storage blog ID for each component' route, which I'm less against now that switch_to_blog() has been recently improved.

It's also a chance for us to take what's broken in WordPress's taxonomy functionality, and fix it before they do. Their long-term plan is to fix the term_taxonomy_id issues, ditch the relationships table, and introduce a term_meta table. We could rebuild XProfile from the ground up like this, and then build a script to migrate the data over during the update process.

We could expand on this concept a bit more, and introduce a set of global field/data/meta tables for any component to use. We can eliminate the field groups table completely by making a "group" another type of "field."

  • bp_fields
  • bp_field_data
  • bp_field_meta

Then we can take the best of both taxonomies and profile fields, and use them for Group Component fields (rather than stuffing it all in meta) or any other component that needs arbitrary field/data/meta can access those tables in an efficient way.

This, in turn, opens up BuddyPress to having true access control, as we could ultimately query more complex datasets without needing to LEFT JOIN a thousand times, or run several uncached queries to get up-to-date data.

Very high level thoughts, but I like getting the discussion going. Thanks for opening this ticket, and I'm excited to see where it leads. Let's start dreaming up the optimal field data schema for this, and forge it into something we aren't limited by in the long term.

#2 @sooskriszta
11 years ago

  • Cc vpundir@… added

#3 @sooskriszta
11 years ago

The ability to run complex queries cheaply and scalably will be invaluable for BuddyPress's future.

For starters, it will enable proper member search #4541 which will be useful for many, many communities. In fact, it could enable BuddyPress to host some types of communities that have so far not been a core target.
e.g.

  • Meetup-type, user-group communities - if I can find everyone in the community between 18 and 34 who's interested in kite surfing, I could create a new group on kite surfing and invite them all
  • Professional listings - if I can easily find an illustrator with 5* expertise in CorelDraw in Camden, why wouldn't I use BuddyPress?
  • Churches, Volunteer organizations, Schools etc - Sure, many of them already use BuddyPress. But if I can easily find folks who are in town this weekend, then I wouldn't have to use other software/services to create and manage a list of who's going to the Habitat for Humanity work site this weekend.
  • Directories/Catalogs - This will make JJJ cringe, but a parameter-based search could make BuddyPress a contender for catalog software, e.g. I can find all movies directed by Hitchcock between 1940 and 1946? Wow! Okay, maybe I went a little bit too far out with this one. But the first 3 use-cases are legit.
Last edited 11 years ago by sooskriszta (previous) (diff)

#4 @sooskriszta
10 years ago

Hey guys, how are you thinking about this? Appropriate for 2.0?

#5 @sooskriszta
10 years ago

  • Cc vivek@… added

#6 @emzo
10 years ago

  • Cc emzo added

#7 @jchristopher
10 years ago

  • Cc jonathan@… added

#9 follow-up: @sooskriszta
10 years ago

Would this become any easier once @DJPaul has completed #5220 ?

#10 in reply to: ↑ 9 @boonebgorges
10 years ago

Replying to sooskriszta:

Would this become any easier once @DJPaul has completed #5220 ?

Yes, it'll at least be easier to build a proof of concept once that work is done.

#11 @sooskriszta
10 years ago

Yay! Now that #5220 is done, I hope and pray this is moved to milestone 2.1

#12 @raptor235
10 years ago

Any updates on the direction of this ticket?

#13 @sooskriszta
9 years ago

Early candidate for inclusion in 2.2?

#14 @boonebgorges
9 years ago

Any updates on the direction of this ticket?

No, but see #5839 for a related discussion.

#15 @DJPaul
6 years ago

  • Keywords trac-tidy-2018 added

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: https://make.wordpress.org/chat/

#16 @DJPaul
6 years ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.