[buddypress-trac] [BuddyPress] #4796: Use taxonomies instead of/in addition to BP Xprofile tables

buddypress-trac noreply at wordpress.org
Thu Jan 31 17:52:13 UTC 2013


#4796: Use taxonomies instead of/in addition to BP Xprofile tables
--------------------------+-----------------------------
 Reporter:  boonebgorges  |       Owner:  boonebgorges
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  XProfile      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+-----------------------------

Comment (by johnjamesjacoby):

 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.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4796#comment:1>
BuddyPress <http://buddypress.org/>
BuddyPress


More information about the buddypress-trac mailing list