epriestley 000760b645 Do a better job of handling spec errors during schema adjustment ... Summary: Ref T1191. Currently if a developer forgot to specify a column type, `storage adjust` aborts explosively mid-stream. Instead: - Make this a formal error with an unambiugous name/description instead of something you sort of infer by seeing "<unknown>". - Make this error prevent generation of adjustment warnings, so we don't try to `ALTER TABLE t CHANGE COLUMN c <unknown>`, which is nonsense. - When schemata errors exist, surface them prominiently in `storage adjust`. Overall: - Once `storage upgrade` runs `storage adjust` automatically (soon), this will make it relatively difficult to miss these errors. - Letting these errors slip through no longer escalates into a more severe issue. Test Plan: Commented out the recent `mailKey` spec and ran `storage adjust`: ``` $ ./bin/storage adjust --force Verifying database schemata... Found no adjustments for schemata. Target Error phabricator2_phriction.phriction_document.mailKey Column Has No Specification SCHEMATA ERRORS The schemata have serious errors (detailed above) which the adjustment workflow can not fix. If you are not developing Phabricator itself, report this issue to the upstream. If you are developing Phabricator, these errors usually indicate that your schema specifications do not agree with the schemata your code actually builds. ``` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10771		2014-11-04 04:42:05 -08:00
..
workflow	Do a better job of handling spec errors during schema adjustment	2014-11-04 04:42:05 -08:00
PhabricatorStorageManagementAPI.php	Fix various MySQL version issues with new charset stuff	2014-10-29 15:49:29 -07:00
PhabricatorStoragePatch.php	Mark dead databases as "dead" and don't dump, probe, or list them	2013-07-19 11:07:29 -07:00