[buddypress-trac] [BuddyPress Trac] #6789: XProfile: do not store serialized arrays for multi-value profile field data

[buddypress-trac]

#6789: XProfile: do not store serialized arrays for multi-value profile field data
----------------------------------+-----------------------------
 Reporter:  Offereins             |       Owner:
     Type:  enhancement           |      Status:  new
 Priority:  normal                |   Milestone:  Future Release
Component:  Component - XProfile  |     Version:
 Severity:  normal                |  Resolution:
 Keywords:                        |
----------------------------------+-----------------------------
Changes (by boonebgorges):

 * milestone:  Awaiting Review => Future Release


Comment:

 First, <3. It would be great to do away with this kind of serialized data.

 Second, some initial thoughts.

 * The most obvious way to store the data is to split individual entries
 into their own rows in `wp_bp_xprofile_data`.
 * But this will mean that user_id+field_id will no longer be a de facto
 unique identifier for `xprofile_data`. That is, a given user may have more
 than one row in `xprofile_data` corresponding to a given field.
 * Various parts of our query API expect to pull only a single row from the
 table. Eg, `BP_XProfile_ProfileData::populate()`, which does
 `$wpdb->get_row()`. In this case we'll probably need to do `get_results()`
 and then figure out how far up the stack we need to add support for
 arrays. Another example is `BP_XProfile_ProfileData::get_data_for_user()`,
 which keys data by field_id. Here, we'll either need to do the array
 conversion right in the query method (so the data structure can remain the
 same in, eg, `BP_XProfile_Group::get()`, or we'll have to change the way
 data is keyed and then make necessary modifications to consuming methods.
 * In all of these cases, we're going to have to weigh backward
 compatibility against design. Returning arrays from functions that didn't
 previous return arrays is almost certainly going to break something
 somewhere.
 * We should do a scan for plugins that interact directly with the
 `xprofile_data` table, especially those that expect serialized data. If we
 find that lots of folks are doing this, we may decide to provide legacy
 support for it. We did something similar with user `last_activity` data
 (you can continue to access/modify the data in usermeta, though BP throws
 a bunch of `_doing_it_wrong()` notices). Ideally, we would simply drop
 support for this kind of direct access; but this will take some good
 documentation and publicity.
 * The migration/update routine is going to be pretty large, and will
 probably need to be broken into chunks. We can do some background
 migration (eg, fire off a cron job during update that migrates data in
 batches), but since this is asynchronous, we'd need to maintain backward
 compatibility for the old data format, at least for a version or two.

 Would love to hear more thoughts on any of the above, or anything I am
 overlooking :)

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