Page MenuHomePhabricator

Add a UI for reviewing database schemata
ClosedPublic

Authored by epriestley on Sep 15 2014, 12:41 PM.

Details

Summary

Ref T1191. Plan here is:

  • Build a tool showing the current schemata status (this diff).
  • Have it compare the current status to the desired status (partly here, mostly in future diffs).
  • Then add a migration tool, and eventually a setup issue to tell people to run it.
Test Plan

Reviewed current schemata.

Screen_Shot_2014-09-15_at_5.34.26_AM.png (1×1 px, 141 KB)

Screen_Shot_2014-09-15_at_5.34.29_AM.png (1×1 px, 160 KB)

Screen_Shot_2014-09-15_at_5.34.23_AM.png (1×1 px, 266 KB)

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Add a UI for reviewing database schemata.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: btrahan.
btrahan edited edge metadata.

This is the sort of thing we would not need at all in a SaaS world but the open source folks need, right?

This revision is now accepted and ready to land.Sep 16 2014, 6:32 PM

The motivation here is entirely to make fixing T1191 manageable, which is purely a support issue (lots of users hit issues with 4-byte characters in commit messages right now, in particular, which is a fairly serious error with no real workaround).

T1191 is scary since it involves a lot of schema changes. Roughly, we need to change every utf8 column to a utf8mb4 column.

A "shorter" path to solving T1191 is to add a huge migration which just swaps every table to the "best" character set and collation. This is roughly what we did to move to utf8 in the first place. However:

  • This would be a huge amount of mandatory downtime for all installs as we swap almost every table's collations.
  • If MySQL doesn't support utf8mb4 at the time we run the migration, we'll pick "binary", and there'd be no way for installs to upgrade later.
  • There's a ton of room for human error, and we have far more tables now than we did the first time around.
  • We got this wrong the first time around, although this wasn't clear at the time.

So this is a more supportable approach: build visual tools so users can understand/screenshot issues and to help catch human errors, make the migration independent of mainline schema changes so installs don't have to do it (at least, not all at once, for now) and so it can be reversed or upgraded later, allow the migration to apply partially, and give us tools to fix issues and make similar changes in the future.

This revision was automatically updated to reflect the committed changes.