[buddypress-trac] [BuddyPress Trac] #6841: Framework for bulk data handling after updates

[buddypress-trac]

#6841: Framework for bulk data handling after updates
----------------------------------+------------------------------
 Reporter:  boonebgorges          |       Owner:
     Type:  enhancement           |      Status:  new
 Priority:  normal                |   Milestone:  Awaiting Review
Component:  API - Update/Install  |     Version:
 Severity:  normal                |  Resolution:
 Keywords:                        |
----------------------------------+------------------------------

Comment (by boonebgorges):

 > For live sites, I don't think any of these solutions are viable. Any
 active site will run into partially migrated data resulting in malformed
 objects, incomplete data-sets, and eventually cache pollution.

 I'm not worried about cache pollution per se (at least not at the object
 cache, which we handle), but I too am concerned about how we're going to
 deal with partially migrated data on a live site.

 Whatever we do, version x.y always has to be prepared for the data schema
 of version x.y-1 (and maybe further back), because we can't depend on the
 migration being immediate. johnjamesjacoby's suggestion is appealing
 because it means that the backward compatibility can look like this:

 {{{
 if ( we have done the migration ) {
     do the new stuff
 } else {
     do the old stuff
 }
 }}}

 instead of having to accommodate mixed cases.

 > For potentially large data migrations, I'd like to propose instead that
 we copy existing tables into temporary tables, perform an Ajax style
 migration similar to bbPress 2's converter tool, check the validity of the
 migration, and then rename tables only once an administrator can confirm
 that everything looks right.

 I think this is a good idea, though I'm unsure what the "confirm that
 everything looks right" part would look like. If we have automated ways of
 checking data integrity, and the migration passes muster according to
 these tools, then in what situation would the admin want to reject or
 postpone the migration? Seems unlikely that you would, say, examine every
 database row by hand to make sure they are ok?

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