phorge-phorge/resources/sql/autopatches/20140420.rel.1.objectphid.sql

ALTER TABLE {$NAMESPACE}_releeph.releeph_request
  ADD COLUMN requestedObjectPHID VARCHAR(64) COLLATE utf8_bin NOT NULL;

ALTER TABLE {$NAMESPACE}_releeph.releeph_request
  ADD KEY `key_requestedObject` (requestedObjectPHID);
Add "requestedObjectPHID" to ReleephRequest Summary: Ref T3551. Currently, ReleephRequests don't have a direct concept of the //object// being requested. You can request `D123`, but that is just a convenient way to write `rXyyyy`. When the UI wants to display information about a revision, it deduces it by examining the commit. This is primarily an attack on T3551, so we don't need to load <commit -> edge -> revision> (in an ad-hoc way) to get revisions. Instead, when you request a revision we keep track of it and can load it directly later. Later, this will let us do more things: for example, if you request a branch, we can automatically update the commits (as GitHub does), etc. (Repository branches will need PHIDs first, of course.) This adds and populates the column but doesn't use it yet. The second part of the migration could safely be run while Phabricator is up, although even for Facebook this table is probably quite small. Test Plan: - Ran migration. - Verified existing requests associated sensibly. - Created a new commit request. - Created a new revision request. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3551 Differential Revision: https://secure.phabricator.com/D8822 2014-04-20 20:55:18 +02:00			`ALTER TABLE {$NAMESPACE}_releeph.releeph_request`
			`ADD COLUMN requestedObjectPHID VARCHAR(64) COLLATE utf8_bin NOT NULL;`

			`ALTER TABLE {$NAMESPACE}_releeph.releeph_request`
			ADD KEY `key_requestedObject` (requestedObjectPHID);