[buddypress-trac] [BuddyPress Trac] #6350: XProfile field database schema

[buddypress-trac]

#6350: XProfile field database schema
----------------------------------+----------------------------------
 Reporter:  johnjamesjacoby       |       Owner:
     Type:  defect (bug)          |      Status:  new
 Priority:  low                   |   Milestone:  Under Consideration
Component:  Component - XProfile  |     Version:  1.0
 Severity:  minor                 |  Resolution:
 Keywords:  2nd-opinion           |
----------------------------------+----------------------------------

Comment (by johnjamesjacoby):

 Replying to [comment:5 DJPaul]:
 > JJJ, I think this looks OK, but I think it would help illustrate some of
 your bullet points if you could please provide a (sample) MySQL export of
 these tables so the rest of us can compare how the default xprofile
 group/field/data/values would relate to each other, and understand the
 proposed changes better (against our development databases, for example).
 Are you asking for a dump of data from the existing tables? If so, this
 seems like a strange request considering how easy it is to just create a
 few fields and groups in your own test installation.

 Are you asking for a dump of data from new database tables? This seems
 less strange, though requires more work than I've put into this theory so
 far. I'm happy to do it, it just contradicts a bit with iterating publicly
 on trac (vs. creating huge amounts of code privately.) We shouldn't be
 working alone for weeks and then delivering new shiny; we should all feel
 free to experiment with rough ideas and help them take shape together.

 > > We could move visibility out of field meta
 >
 > I don't see enough benefits to doing this -- unless you can suggest why
 BP would need to be able order fields by visibility when making an SQL
 query. I think the existing JOIN against the meta table for (what is) a
 key/value pair is fine; it only starts to be a hinderance when you try to
 order things by meta value.
 Ordering by visibility doesn't really make any sense in the context of
 profile fields, but it does open up the opportunity for more elaborate
 visibility queries without requiring a JOIN to data in the the unindexed
 meta_value column, but that's also not really the point of this exercise
 either IMO.

 The rub is that the tables in this components schema no longer represent
 it's needs in the most accurate and efficient way; I'm proposing one
 possible alternative, of which there are infinite.

 Imagine if post_status were meta data instead of an indexed column.
 Eventually, for profile fields to be speedy and increasingly complex, it
 would be an obvious improvement to move that out of meta data. Designating
 sign-up fields? Probably less-so, but it would be nice to concentrate a
 bit more on the experience of getting users into the community nicely
 rather than keeping them busy afterwards.

 Since it sounds like the improvements are too vague to be easily imagined,
 I'll spend some time more fully implementing it. Expect me to iterate with
 several patches here.

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