Differential D7726 Diff 17470 resources/sql/patches/20131206.phragment.sql

Changeset View

Standalone View

resources/sql/patches/20131206.phragment.sql

This file was added.

				CREATE TABLE {$NAMESPACE}_phragment.phragment_fragment (
				id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
				phid VARCHAR(64) NOT NULL COLLATE utf8_bin,
				path VARCHAR(254) NOT NULL COLLATE utf8_bin,
				depth INT UNSIGNED NOT NULL,
				latestVersionPHID VARCHAR(64) NOT NULL COLLATE utf8_bin,
				viewPolicy VARCHAR(64) NOT NULL COLLATE utf8_bin,
				epriestleyUnsubmitted Not Done Inline Actions Does giving these an owner really make sense? They seem more like a collective resource (like a repository) than a personal one (like a Paste or Revision). epriestley: Does giving these an owner really make sense? They seem more like a collective resource (like a…
				hach-queAuthorUnsubmitted Not Done Inline Actions It's mainly for policies so that there's always an owner who can recover it. Maybe it's more suitable to just give administrators implicit access to view and edit fragments, what do you think? hach-que: It's mainly for policies so that there's always an owner who can recover it. Maybe it's more…
				editPolicy VARCHAR(64) NOT NULL COLLATE utf8_bin,
				dateCreated INT UNSIGNED NOT NULL,
				dateModified INT UNSIGNED NOT NULL,
				UNIQUE KEY `key_phid` (phid),
				UNIQUE KEY `key_path` (path)
				) ENGINE=InnoDB, COLLATE utf8_general_ci;
				epriestleyUnsubmitted Not Done Inline Actions Add: UNIQUE KEY `key_path` (path) This lets us find fragments by path, and ensures we don't have two with the same path. It is possible `(path, depth)` or an additional `(depth, path)` key would also benefit some queries, but that one's murkier to me; we can wait until we have data. epriestley: Add: UNIQUE KEY `key_path` (path) This lets us find fragments by path, and ensures we don't…
				hach-queAuthorUnsubmitted Not Done Inline Actions Will fix. hach-que: Will fix.

				CREATE TABLE {$NAMESPACE}_phragment.phragment_fragmentversion (
				id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
				phid VARCHAR(64) NOT NULL COLLATE utf8_bin,
				sequence INT UNSIGNED NOT NULL,
				fragmentPHID VARCHAR(64) NOT NULL COLLATE utf8_bin,
				filePHID VARCHAR(64) NULL COLLATE utf8_bin,
				epriestleyUnsubmitted Not Done Inline Actions Maybe make this nullable for the initial write. There's no practical consequence, but `null` is a little cleaner in concept. epriestley: Maybe make this nullable for the initial write. There's no practical consequence, but `null` is…
				hach-queAuthorUnsubmitted Not Done Inline Actions In a later diff I reverse the logic here so that `latestVersionPHID` can be null on the fragment and the fragment gets saved before the first patch is assigned. Making `latestVersionPHID` nullable has to be done to support directory fragments, so I can bring that change forward into this diff if required. hach-que: In a later diff I reverse the logic here so that `latestVersionPHID` can be null on the…
				dateCreated INT UNSIGNED NOT NULL,
				dateModified INT UNSIGNED NOT NULL,
				UNIQUE KEY `key_version` (fragmentPHID, sequence)
				) ENGINE=InnoDB, COLLATE utf8_general_ci;
				epriestleyUnsubmitted Not Done Inline Actions Add: UNIQUE KEY `key_phid` (phid) The `key_version` should be: (fragmentPHID, sequence) ...I think? Two reasons on that: Two versions with `<fragmentPHID=X, filePHID=Y, sequence=3>` and `<fragmentPHID=X, filePHID=Z, sequence=3>` are unique on this key, but not valid (they give the fragment two separate entires with sequence = 3). When ordered with `fragmentPHID` first, this key can be used to select a fragment's versions. With `sequence` first, it can't, and we do a table scan. epriestley: Add: UNIQUE KEY `key_phid` (phid) The `key_version` should be: (fragmentPHID, sequence)…
				hach-queAuthorUnsubmitted Not Done Inline Actions Will fix. hach-que: Will fix.