phorge-phorge/scripts/sql/upgrade_schema.php

#!/usr/bin/env php
<?php

echo "This script has been replaced by 'phabricator/bin/storage'.\n\n".
     "Run:\n\n".
     "  phabricator/bin $ ./storage help\n\n".
     "...for help, or:\n\n".
     "  phabricator/bin $ ./storage upgrade\n\n".
     "...to upgrade storage.\n\n";
exit(1);
Schema upgrade script. Summary: Created a script the runs all the necessary patches for db schema. Stores information in the db about the latest patch that was applied. Test Plan: Created two test files '024.test.sql' and '023.test.sql' in this order. '023' creates a database and '024' creates a table in this db. First ran './upgrade_schema.php 23' and made sure that patches were applied in order. Then ran './upgrade_schema.php' to make sure db was up-to-date. Checked manually from the db that the database and table exists. Reviewed By: epriestley Reviewers: epriestley CC: jungejason, epriestley, tuomaspelkonen Differential Revision: 115 2011-04-07 16:55:32 -07:00			`#!/usr/bin/env php`
			`<?php`

Make SQL patch management DAG-based and provide namespace support Summary: This addresses three issues with the current patch management system: # Two people developing at the same time often pick the same SQL patch number, and then have to go rename it. The system catches this, but it's silly. # Second/third-party developers can't use the same system to manage auxiliary storage they may want to add. # There's no way to build mock databases for unit tests that need to do reads. To resolve these things, you can now name your patches whatever you want and conflicts are just merge conflicts, which are less of a pain to fix than filename conflicts. Dependencies are now a DAG, with implicit dependencies created on the prior patch if no dependencies are specified. Developers can add new concrete subclasses of `PhabricatorSQLPatchList` to add storage management, and define the dependency branchpoint of their patches so they apply in the correct order (although, generally, they should not depend on the mainline patches, presumably). The commands `storage upgrade --namespace test1234` and `storage destroy --namespace test1234` will allow unit tests to build and destroy MySQL storage. A "quickstart" mode allows an upgrade from scratch in ~1200ms. Destruction takes about 200ms. These seem like fairily reasonable costs to actually use in tests. Building from scratch patch-by-patch takes about 6000ms. Test Plan: - Created new databases from scratch with and without quickstart in a separate test namespace. Pointed the webapp at the test namespaces, browsed around, everything looked good. - Compared quickstart and no-quickstart dump states, they're identical except for mysqldump timestamps and a few similar things. - Upgraded a legacy database to the new storage format. - Destroyed / dumped storage. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2323 2012-04-30 07:54:00 -07:00			`echo "This script has been replaced by 'phabricator/bin/storage'.\n\n".`
			`"Run:\n\n".`
			`" phabricator/bin $ ./storage help\n\n".`
			`"...for help, or:\n\n".`
			`" phabricator/bin $ ./storage upgrade\n\n".`
			`"...to upgrade storage.\n\n";`
			`exit(1);`